I am creating a WPF Office add in, and I would like to handle all exceptions in one place. To do this I use the following code in the constructor of my MainWindowViewModel:
Dispatcher.CurrentDispatcher.UnhandledExceptionFilter += new
DispatcherUnhandledExceptionFilterEventHandler(HandleAllException);
In my test environment I host the WPF app from a console application project, and exceptions are handled as expected. When I host the WPF app from within word however, nothing happens when exceptions are thrown. There is no notification at all that there has even been an exception, other than in the output window in visual studio. Does anyone have any suggestions as to what I might be doing wrong?
I have solved the problem by changing the way in which I launch my WPF app. I believe the problem was related to this.
Related
I have a WinForms VB app, using Visual Studio 2010. I am using the WPF DocumentViewer, so it is hosted by the ElementHost control. In my AppMain_Form.Designer.vb, when the follopwing (generated) statement is executed:
Me.rv_doc_vwr_host = New System.Windows.Forms.Integration.ElementHost()
I get an exception (which I had to enable CLR exceptions for the debugger to get):
"The calling thread must be STA, because many UI components require this."
However, in my research for this problem, I found the following:
1) Windows Forms applications are SingleThreaded by default.
2) The Main procedure is generated automatically for Windows Forms applications, and it is hidden.
3) A Main procedure can be manually coded, but this requires disabling the Application Framework, which I believe is rather necessary for a Windows Forms application.
So, why is this exception occurring if the Windows Forms application is SingleThreaded by default? If not, how can I mark the Main procedure as STAThread if it is hidden? Why did I have to enable CLR exceptions to catch this? Prior to enabling CLR exceptions, this did not show up in my testing, but when I ran my app outside of Visual Studio, it displayed an exception box briefly about creating the main form, but before I could get any details it was replaced by my splash screen, then my main form. The app worked normally after that. However, I cannot deploy it with an exception message being displayed every time it starts up.
I have a winforms application opening a wpf window. I've used both methods below:
System.Windows.Forms.Integration.ElementHost.EnableModelessKeyboardInterop(window)
and
Dim helper As System.Windows.Interop.WindowInteropHelper = New System.Windows.Interop.WindowInteropHelper(window)
helper.Owner = Me.Handle
I've opted to use the second method, as the application, in random occasions, will fail to display the content of the wpf window, and even crash it. This will occur in different environments (32/64) with xp or 7, and unfortunately, I was never able to reproduce it in development. This window only uses a datagrid, with some interaction done via button controls. Anyways, by switching over to the second method, it seemed to have corrected the issue altogether. The bug has not manifested for months now. However, now I’m adding a textbox control to this window, and noticed that it’s not allowing the text entry, only spaces. If I switch back to the original method, it works, but I’m afraid the issue will start showing up in production again. Has someone come across this issue before? Any advice will be greatly appreciated!
Strange problem here, I have a page with 4 ControlTemplates declared in the page resources. In the code for the page, I declare a reference to each of these ControlTemplates so that I can use them in binding. This works fine Out-Of-Browser, and In-Browser, except when it is running in the Silverlight Web Part in SharePoint. In SharePoint, the buttons that I want templated are shown as just normal buttons with the class as the text instead of the special layout and content I define in the template. Any idea why it would work everywhere but in SharePoint?
While I am not sure what caused the null reference only while being ran in SharePoint, I refactored my code to make the ItemsControl.ItemsSource reference a property instead of a single assignment of a List<> to it. Now it is working just like it should.
Helpful in figuring this out was the ability to attach Visual Studio to the Internet Explorer (didn't work so well for Chrome) process that was running the Silverlight Web Part. This is found in Visual Studio by going to the Tools menu > Attach to Process. Which IE process it is will be obvious as it will have Silverlight in the Type column.
I've been working on a SL5 app for a few days. I've mostly been using a hard coded dummy data collection when styling my app's view. Everything has been working fine, but now I want to connect it to a dynamic data collection generated by my view model (using the data service technique where you have design time & real data depending on the IsInDesignTool property.
After I cleared out the control of the hard coded data and bound it to a collection in my view model. When I run it in debug mode, I see an unhandled exception being thrown in App.xaml.cs. The exception args don't say exactly what the problem is (it is simply saying "Value does not fall within the expected range" but when I look at the sender I find the following coming from the MainWindow (my app only has a single view): "Out-of-browser specific settings do not affect in-browser applications."
Further, when I try to view the MainWindow in the designer in VS, it doesn't render and instead shows an error (the rendered exception in the designer doesn't have any of my namespaces in it, just things about controls & UIElements).
I'm at a bit of a loss how to troubleshoot this. I didn't set anything for out-of-browser when building the app and since it worked with dummy data collections, why would it suddenly have this issue (seems like if I was using an out-of-browser property it would have shown up before I bound the data to the view).
Tips/pointers?
(sorry for my bad english)
I am not sure on what is happening but I saw the error "Out-of-browser specific..." when I tried to access some specific property only available to OOB while running on browser. The solution was to test if running oob before using the property:
if (Application.Current.IsRunningOutOfBrowser)
{
Application.Current.MainWindow.WindowState = WindowState.Maximized;
}
The other problem possibly is unrelated - and sometimes can be really hard to debug - one thing that helped me is to open another instance of VS and attach it to the one where you are seeing the problem. With this setup, go to your problematic View and change to "design view" - keep an eye on the Output window of the attached VS to see if some meaningful exception is shown.
I had a similar issue.
I did put a Textbox inside kind of Listbox (radPanelBar) and added
HorizontalScrollBarVisibility="Auto" to the Textbox. It seems that the textbox had problems when to show the scrollbar and when not. Adding
ScrollViewer.HorizontalScrollBarVisibility="Disabled" to the Listbox did solve it ( so, no OOB issue at all ).
I'm not entirely sure what the error was, but it wasn't at all realted to OOB. I'm using a data service approach (in design time I programatically build real data, not the Expression Blend sample data, but when not in a design tool, it uses the REST services). I started disabling a lot of things in my dynamic data and slowly added them back. Somewhere along the way my dummy data generation was fouling things up, but SL thought it was an OOB issue.
I have an WPF app, all seems to run fine with one exception - the designer rarely, if ever, loads correctly. Usually complaining about Undefined CLR namespace. and then saying it can't find a few of my local: defined controls.
Is this just a defect in the designer or Visual Studios code generation or actually systemic of something wrong with my application?
In your code can be an error which occurs only in design time. It is possible to debug it. See How to: Debug a Designer Load Failure. Shortly you need another instance of Visual Studio and attach it to the one displaying your wpf app. You can even try to follow the error to its roots with How to: Debug .NET Framework Source.
I had a similar problem and I successfully tracked it down to DataContextChanged event handler and got rid of it.