Using the following tutorial, within a VSIX project, I created a WPF window that inherits from Microsoft.VisualStudio.PlatformUI.DialogWindow, and I display this modally using the following code:
var myWindow = new MyWindow(myParameters);
myWindow.ShowDialog();
When I compile this in RELEASE mode and start without debugging [Ctrl+F5], it opens the Experimental version of Visual Studio. Here, I open another Solution and then execute my Modal Window. The window works just fine - I can type in text boxes etc, etc.
However, when I close the modal dialog window [using this.Close()], the problems start. If I navigate to one of the documents in the open solution, I can type, but the keyboard buttons backspace [<-] and [Delete] (and possibly others too) are simply ignored....I can't delete what I've just typed!
Also, when I try to close this experimental version of Visual Studio, I get the following message:
Microsoft Visual Studio has detected that an operation is blocking
user input. This can be caused by an active modal dialog or a task
that needs to block user interaction. Would you like to shut down
anyway?
But, as far as I can tell, my modal window has been closed and may even have been garbage collected by the time I get to close this instance of Visual Studio.
This isn't limited to the Experimental version - when I push this VSIX to our local gallery and install as an Extension, then I get the same behaviour.
I have also tried explicitly setting the owner, but his had no effect on this problem:
var myWindow = new MyWindow(myParameters)
{
Owner = Application.Curent.MainWindow
}
myWindow.ShowDialog();
If I make this a non-modal window, then I get different (but related) problems. Here, if I open the Experimental version of Visual Studio and open the other Solution where I navigate to a C# page. I then open my Extension's WPF window where I can happily type into TextBoxes in that WPF window. However, whenever I click the backspace [<-] or the [delete] keys, this doesn't affect the current WPF textbox but the previously opened C# code window in the current solution. See a previous post on this
What am I missing?
The following suggestion found here seems to work for me:
IVsUIShell uiShell = (IVsUIShell)ServiceProvider.GetService(typeof(SVsUIShell));
uiShell.EnableModeless(0);
var myWindow = new MyWindow(myParameters)
{
Owner = Application.Curent.MainWindow
}
myWindow.ShowDialog();
uiShell.EnableModeless(1);
Related
An application that I've written (https://github.com/JuliusSweetland/OptiKey) requests UIAccess (to be able to be rendered above everything) and has a modal popup window styled using MahApps.Metro. When run on Windows 8/8.1 everything is fine, but on Windows 10 the popup window does not display (is not rendered anywhere), but is visible in the taskbar. Hovering over the thumbnail displays the preview, but the window can never be made visible.
I have narrowed the problem down to Windows 10 and whether the UIAccess="true" setting in the manifest is true/false (it is fine if set to false).
I initially thought the problem was linked to the .Net 2.0.0.0 runtime not being present on a default install of Windows 10, as the problem went away when I installed Snoop (which I think installed .Net 3.5 and so the 2.0.0.0 runtime), but to prove the fix I uninstalled .Net 3.5, which brought back the issue with the child window, and then re-installed .Net 3.5, which did NOT resolve the issue again.
I have tried the following:
Running application as admin = no fix
Updating all graphics drivers = no fix
Checking the event logs = nothing
Converting my child (popup) window to be non-modal = no fix
Converting my child (popup) window to be a standard Window class, rather than a MetroWindow (MahApps) = no fix
4 & 5 = no fix
Installing .Net 3.5 = no fix
The only thing that works is setting UIAccess="false", but I need it to be true.
N.B. UIAccess is working correctly on Windows 8.1, and I have fulfilled the requirements (adding UIAccess="true" to the manifest, signing the assembly, and running from a protected directory "Program Files")
Any idea what is going on?
Found the issue - as part of launching the child window I was setting the parent window's TopMost property to false (and then setting it back to its original value when the child window closed). Something about setting parentWindow.TopMost=false was causing the invisible child window problem. I removed the relevant lines (in this commit: https://github.com/JuliusSweetland/OptiKey/commit/e9031119a726518f54da94c64faceeee991b3747) and everything works again.
I have started a new project using WPF and Catel and I want to be able to have multiple windows without ownership. I have been able to create an application with a standard window and which creates dialogs. I would like to find an example or tutorial on how to create a window and then close the current window.
Example:
Window1 -> Select Open Window2 Button -> Open Window2 -> Close Window1
Thanks
When you call Show on the UIVisualizer, it should show the window non-modal. After calling the UIVisualizer service, just call CloseViewModel on yourself and the current window should close.
It appears that the above answer is correct as long as you are not closing the startup window.
It appears that when you close the ViewModel that is targeted as your startup View\ViewModel when you close it, it closes the whole application.
My question now.. How can I prevent this from happening.
I have a visual c++ program which has a few window forms. It does not have any error and can be built successfully. Today I want to add another textbox and a button to one of the form, but I cannot find out my form design window. I see the Form1.h, Form1.resX and my other stuff. Once again, I can built it and the program does not have any error, but the form design window disappear. Please help.
For VS2008
Click View->Resource View or in the Solution Explorer click the Resource View tab
Under "App.rc" click Dialog, you can view your form there
I'm styling a menu in WPF and would like to see how it looks, without having to launch the application to open the menu.
Is there a way to keep the menu open (so I can see the menu items) at design-time, so I can see the changes as I go?
I currently only have Visual Studio 2010 to work with.
You can set IsSubmenuOpen="True", but if you click somewhere else, menu will close. Set it again to open.
You should be able to see changes in the design window as soon as you make changes - are you using VS2010 express? I found that in express the designer didn't refresh when I made style changes - I had to close/re-open the form to see the changes reflected. You shouldn't need to build to see design changes unless of course you are adding new user controls etc that need to be built before the designer can process them
I have a strange problem here. I've created a simple plugin using the wizard for a Visual Studio Integration Package / VSIX project with a tool window. Within that window I want to do a simple drag/drop from a listbox and drop within the same window. I've done the same thing in a normal WPF program, but when I do this in a WS toolwindow it's not allowed. I start the drag/drop operation (initiated by a PreviewMouseLeftButtonDown event) and call the DragDrop.DoDragDrop() method, I get the stop-sign-cursor at once. No dragging allowed.
Any ideas? Security restrictions or an effect of the fact that these WPF controls are hosted inside a ToolWindowPane and old Visual Studio IDE COM stuff I guess... Thanks for any help!
Alin Constantin at Microsoft helped me out here and has even written a blog post on how to do drag/drop within VS2010 properly!
http://alinconstantin.blogspot.com/2010/02/drag-and-drop-in-visual-studio-2010.html
Highlights, in case of link rot:
In your tool window (the UserControl), override OnDragEnter, OnDragOver (important!) and OnDrop. Failure to override OnDragOver will cause drag/drop to fail.
In OnDragEnter, do the following:
Check to see if you can handle the drop
If so, set DragEventArgs.Handled to true and DragEventArgs.Effects to the appropriate value
Call base.OnDragEnter()
In OnDragOver, you must do the same thing as OnDragEnter. If you fail to set Handled, Visual Studio will take over and you won't be able to handle the drop!
In OnDrop,
Handle the drop
Set DragEventArgs.Handled to true
Call base.OnDrop()
Remember, not handling OnDragOver will result in Visual Studio taking over the drag operation, denying you the ability to handle it in OnDrop.