I am having a hard time to create an exception handler in a WPF application coded in VB.net.
I already read a tons of articles on the internet, but most of them only work in WindowsForms or are written in C#.
The thing I like is a simple MessageBox with the crash reason when the application is crashing.
I think this here
should be the way to go, but I cannot get it to work, since it seems to be for Windows Forms.
Visual Studio show multiple errors, mainly because it is not finding the UnhandledException event...
I would be really grateful about an explanation how to get the think I try to get.
Edit: Something like this
You're probably looking for Application.DispatcherUnhandledException event.
In App.xaml you need to add a handler for this event:
<Application DispatcherUnhandledException="DispatcherUnhandledExceptionEventHandler" .../>
Then in code behind you can write your code for handling the exception:
Private Sub App_DispatcherUnhandledException(ByVal sender As Object, ByVal e As DispatcherUnhandledExceptionEventArgs)
' Process unhandled exception
e.Handled = True
End Sub
Here you can find more information, even with sample code in Visual Basic.
Related
I am using a C1ReportViewer control, and have already posted a question on the C1 forums, however i thought i would post here as well to see if anyone had run across a similar issue. The control uses the generic silverlight PrintDocument() method.
When printing a Crystal Report from this control in Silverlight 5 sometimes the report prints out garbled, meaning different sized text, tapered lines and generally out of position. It also rarely prints the entire report.
I have narrowed the issue down to a few printers, and only with machines using their 32 bit drivers. Based upon this, and the changes made to Silverlight 5, i am assuming the issue revolves around PostScript compatibility. However, as our product is LOB application, enforcing PS compatible printers and printer drivers is nearly out of the question.
Accordingly, if this is indeed a post script issue, based upon the documentation for silverlight 5, the PrintDocument() method should be failing back to the default bitmap method. See Am I correct in understanding that vector printing in SilverLight 5 will only work with a Postscript printer?
My question for stackoverflow is: Has anyone encountered a similar issue in with printing in Silverlight 5, or has anyone had success printing Crystal Reports/PDFs? And in the off chance that anyone has, what solutions have you come up with?
Much Appreciated,
Greg
I was able to come up with a solution for this. Instead of using the built in C1 Printing functionality I was able to write some code to force bitmap printing.
First i created a new PrintDocument, and hooked up some handlers for its PrintPage event.
mobjPrintDocument = New PrintDocument
RemoveHandler mobjPrintDocument.PrintPage, AddressOf Print_Report
AddHandler mobjPrintDocument.PrintPage, AddressOf Print_Report
Then we can call the PrintBitmap function on the PrintDocument whenever you want to print. Here I am doing it when the user clicks the Print button.
Private Sub xbtnPrint_Click(sender As System.Object, e As System.Windows.RoutedEventArgs)
mintPageIndex = 0
mobjPrintDocument.PrintBitmap(FileName)
End Sub
Now comes the important part. We can hijack the content targeted by hooking into the PrintPage event (as handled above). I can set the e.PageVisual to any visual xaml element and the PrintBitmap will handle it. Here I use the GetPages function and loop through to make sure I print each page (a pdfviewer element). However, you can point it to any visual element like I said.
Private Sub Print_Report(sender As System.Object, e As PrintPageEventArgs)
e.PageVisual = xobjReportViewer.GetPages(mintPageIndex)
mintPageIndex += 1
e.HasMorePages = mintPageIndex < xobjReportViewer.GetPages.Count
End Sub
The e.HasMorePages allows you to force the firing of this event until you are finished.
Hope this is helpful to someone. With Silverlight 5 and the Post-Script printer support, alot of printers that have a PostScript emulator may not be compatible, but will also not default to bitmap printing. This workaround fixes that, making printing a little bit more stable in a LOB type application.
I've read a lot of questions on SOF and links (for example http://www.beacosta.com/blog/?p=52)
But is there easy way to know what exact file I should look into when Binding fails?
If we have one Application and a lot of forms, it can be difficult too.
Have you tried checking "Thrown" for the exception in question in the Debug->Exceptions menu.
E.g. if you get
System.Windows.Data Error: 35 : BindingExpression path error ...
Then you can tell the debugger to break on it by checking "Thrown" under Common Language Runtime Exceptions -> System.Data -> System.DataException. This is however, only useful if the exception originally occurs in your code. Other exceptions, such as binding to non-existing properties and so on will silently fail and only print in the Output window. There is some discussion on http://visualstudio.uservoice.com for improving XAML debugging
I just found the most WONDERFUL post when looking for this. It is a listener that listens for binding errors and throws up a message box with details. It only works when running from within Visual Studio, so you won't show it to your users. Two steps - copy the class into your project, and set the listener in your main window.
http://tech.pro/tutorial/940/wpf-snippet-detecting-binding-errors
You can use Snoop for this: http://snoopwpf.codeplex.com/
Just use Snoop to point to your application and then you can sort on Binding Errors. All Bindings Errors will be highlighted in RED, and show the property of the control.
I'm using Visual Studio 2010 to create a small WPF application. I've created a user control that I am now trying to add to my main form. The user control does show up in toolbox but every time I try to drag the control to the form I get the error:
The enumerator is not valid because the collection changed.
I should know what's wrong and it is bugging me that I can't figure it out.
You have a bug in the constructor of the usercontrol - you are using a foreach-loop over an IEnumerable and while the loop is running, the IEnumerable is changed, this is not allowed with a foreach loop. Use a for loop instead if you are manipulating the Collection you are iterating over.
The problem here is that you don't know what code is throwing the exception.
WPF is terrible about exceptions, especially in constructors. The framework insists on catching and re-throwing a new exception, usually multiple times, and it's difficult to find the original stack trace. I've found the easiest way to track down this kind of error is to tell Visual Studio to stop as soon as the exception is thrown, rather than waiting until WPF has re-thrown it a couple of times and made the details difficult to dig out.
I don't have Visual Studio 2010 in front of me, but here's how to do this in VS2008 -- 2010 is probably similar:
Go to the Debug menu > Exceptions...
Next to "Common Runtime Language Exceptions", check the box in the "Thrown" column
Then debug your app again. It will stop at the line that's actually causing the problem, and it'll be much easier for you to see what's going on. And if you're still not sure why it's throwing an exception, you'll be able to post a code sample.
In order for a user control to function properly you need to have a constructor that takes zero arguments. This way the form designer has a way to render the control in a "default" manner.
I then overloaded my constructor to take the arguments I needed to actually run the control properly and everything worked as expected.
You need to:
Remove the DLL reference
Add a reference to your control
Rebuild the solution
Add your control. It should work!
If anyone can provide some help for this one, I'd be very grateful!
We are using: Silverlight 3 / MVVM / Blacklight DragDock Control / ComponentOne Silverlight Controls
I have a Silverlight application that relies heavily on the MVVM pattern. The application has seemingly been running fine, until recently. I have started to notice semi-random (semi-random = over a long enough period of time ~2 - 5 mins) I can reproduce a System.ExecutionEngineException coming from the PropertyChanged event being raised. The property name which the notification is being raised for is not always the same property name (the firing of the property change event happens in a base ViewModel class).
The code basically looks like this:
if (PropertyChanged != null) Application.Current.RootVisual.Dispatcher.BeginInvoke( () => PropertyChanged(this, new PropertyChangedEventArgs(propertyName)));
The code works for everything else in the application. Basically everything that throws off a property changed event goes through this. I'm not sure why this is failing all of a sudden. Please throw some thoughts my way.
I've been knee deep in windbg trying to get some grasp on what is going on, and still have very little. I'd by happy provide a dump or any other information that might be helpful. Obviously, there is very little information given from this particular error...
Thank you ahead of time, David Justice
A question you might ask yourself: is this ExecutionEngineException happening in IE only and, for instance, not in FireFox?
I know Silverlight is supposed to be browser-independent, but I already encountered a similar known Silverlight-issue that occured randomly in IE only.
The fact that you get an ExecutionEngineException is pointing out that the SL runtime blows up for some reason.
This exception is quite the exotic one. If one gets thrown, it's Game Over, 0 Continues for the CLR. No managed code can catch that exception.
When I ran into it, it was the result of a driver writing into a buffer that wasn't marshaled properly and so was not pinned, and the CLR moved the buffer while the driver was writing into it. It wouldn't crash instantly, but usually happened after the mouse ran over the form's menu bar (which probably resulted in creating and destroying lots of small objects, which then lead to the CLR running the GC and compacting the managed heap). Even though one of my worker threads was communicating with the driver, it was the main thread that threw the exception, which made things way more confusing.
Make sure things are being marshaled properly. If ANYTHING is being passed back and forth to unmanaged code, make sure you use GCHandle to pin the objects.
I have a base Windows Form with a control. I have declared the control to be protected so his siblings will be able to handle properties, methods and events. This form is written in c#.
One of my clients is using VB.NET, and they have created a new inherited form in their project. Everything works fine ...
But, When they want to handle the control's clicked event in vb.net they're getting this error message:
"Handles clause requires a WithEvents variable defined in the containing type or one of its base types".
Can anybody tell me what should i do on the c# form to let the inherited form in vb.net use the control events?
Thanks for your help!
Two options:
Write some VB which declares a protected WithEvents variable, then decompile it to see what the VB compiler does. (I believe that it makes it a property for one thing, and probably adds a bunch of other bits and pieces.)
Tell them not to use a Handles clause - get them to subscribe explicitly in the same way that you would from C#, using AddHandler and AddressOf.