If I make non-modal window I get different problems. Firts of all I open the Experimental version of Visual Studio and open a Solution where I navigate to a C# page. Then I 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. I open my window in this way:
window = new MyWindow()
window.show();
I know that I could resolve my problem with :
uiShell.EnableModeless(0);
window = new MyWindow()
window.ShowDialog();
uiShell.EnableModeless(1);
But I don't want this solution. I want to navigate file in visual studio shell and at the same time using my addin without having problem with input. How Can I resolve this problem using Show() ?
If you want to display a "non-modal" window, it needs to be a toolwindow, or a document window. Otherwise, VS will not know about it, and you'll encounter all sorts of problems with it not getting messages, events, accelerators, etc...
If you want a modal window, use the DialogWindow class as previously mentioned to ensure the IDE can properly disable/enable it's windows when the dialog is displayed or dismissed.
Sincerely,
Related
I have an MFC window-based app. I added a C# class library that provides a second window for login to the app. This second window is meant to show before the main MFC window and once the user successfully logs in, it will go away and the main window will launch. The problem I am having is that when the login window is showing there is no taskbar icon for it. This did work correctly when the login window was an MFC dialog.
To make debugging this window easier I made a small MFC test app from which I can launch the login window with a button click. (the main program is cumbersome to test with). I added a C# class library to it just as it is in the main program. When I launch the app the main MFC dialog app shows up and the app's icon appears on the taskbar. When I click the button to launch the WPF window, it appears but there is no icon in the taskbar. This window does not show on the taskbar as a second window of the app as I would expect.
I am having a really hard time with google finding relevant info.
I have tried specifying an icon for the window vs. not specifying one.
I have tried adding ShowInTaskbar="True" to the window.
I have tried changing WindowStyle
I have tried playing with TaskbarItemInfo.
I tried following New taskbar icon when opening a window in WPF, but I don't really understand it well enough to say that it will fix my issue since I do not get my window showing up at all and if I did I would be fine with it being stacked.
I am not sure where else to go with this. Please let me know if there is anything unclear.
I was wondering if there is a window property, for a wpf application, that disables any actions outside of the window. For example, when you open a message dialog and click outside of it, the message dialog background flashes. Kind of saying you can't do any actions outside of the message dialog untill you click the 'OK' button. I want that implemented in some windows that I open in a program i'm developing but can't seem to find any info on it. Looking for ways on how i might approach this.
Try ShowDialog() instead of Show()
Opens a window and returns only when the newly opened window is closed.
Window childWindow = new Window();
childWindow.ShowDialog();
Note that it will prevent clicks only on parent window(s). Clicks on other applications or Desktop can't be prevented by the Dialog.
I am currently working on AX form for automation . In one of the forms, I am trying to click a button , which opens another form and on this form I need to perform some action.
The window which I am opening on button click sometime opens in background and few times pop up in the foreground above the window where I have clicked the button.
I would want my window to open in the foreground so that I can perform operation , since it is opening in background the codedui playback is searching for the controls on the main window/parent window, which making test case fail
This is making my test case fails multiple times. I am using SetFocus property and SearchInMinimizedwindow options but none of them is working
Is there any solution to always get the window on foreground in codedui or in c#
I would suspect the popup window has some of the same automation properties as the parent window. If not able to fix this code side by using a different AutomationId, you may be able to workaround this by specifiying this is a different window instance.
SecondWindow.SearchProperties["Instance"] = 2;
SecondWindow.SetFocus();
The window that opens when you click the button, is that the child window of the Main window or does it exist on its own? Based on that, you will have to search on the parent (Main Window or Desktop).
I'm programming a simple DialogPropertyValueEditor for a property of a User Control.
So I have three projects in my solution:
MyUsercontrolProject
MyUsercontrolProject.Design
WPFWindowTest
The MyUsercontrolProject.Design contains a WPF window (call it QueryDesigner) that has to be open when the user click the "..." button on the Usercontrol's property in WPFWindowTest.
The problem is that everytime I made a change in MyUsercontrolProject.Design the WPFWindowTest project fails to load the QueryDesigner window with the message:
MyUsercontrolProject.Design.QueryDesigner does not have a resource identified by the URI '/MyUsercontrolProject.Design;component/DesignerFolder/queryDesigner.xaml'.
I need to perform a random series of Close/Open/Recompile/Clean to have the window showed.
Can you please help me to solve this issue?
I have noticed some strange form interactions while using a ContextMenuStrip or a MenuStrip. I don't really know what is causing it so the following should create a repeatable test for anyone looking into this:
I've created two Windows Forms: Form1 and Form2. Both have a MenuStrip added to them. Both are set to StartPosition = CenterScreen.
Form1 has a simple menu like this: Form2 > Open. Clicking "Open" will launch Form2.
Form2 has a simple menu like this: Try to open > anotherTestMenuItem
Start the program. Form1 opens.
Open Form2 from Form1 (i.e. click Form2 > Open).
Form2 appears.
On Form2, try to open the MenuStrip (click Try to open). Form1 will reappear over Form2, although Form2 still has focus (you can see this if you move Form2 a little before trying to open the menu).
If I set Form2's owner to Form1, Form2 remains visible when you try Step 4, but the menu doesn't display the first time. All subsequent clicks seem fine.
I noticed this when I tried opening a context menu (on a form opened by another form) and it would disappear immediately, but only the first time. Every time thereafter it would open normally.
Does anyone have any ideas as to what is going on?
Yes, this is a known bug in the RTM version of .NET 4.5. This KB article mentions it:
When you click a menu item to open a child window in the application, interactions with the menu and child windows behave incorrectly.
For example, you may experience the following:
- When you open a shortcut menu in the child window, the main window form takes the focus.
- You cannot use mnemonics to access a menu item.
As you can tell from the KB article, this bug was fixed quite a while ago. The bug fix was incorporated in a maintenance release first made available on January 8th of 2013. Be sure to allow Windows Update to deploy that update on your machine. Or download it from here.
Check to see that you have:
"AutoValidate" set to "EnablePreventFocusChange"
Make sure you do not call the Hide method for a menu or contextmenu during its item-click handler. I was in the habit of doing this during development to get a menu off the screen while I stepped through debugging code. However when I launched a secondary form from such a menu, the first right-click in the new form would cause the focus to revert to the primary form, sometimes even if I had left-clicked or typed something in the new form. I don't recall if I found this solution online somewhere or discovered it myself. This may not be the same bug mentioned above, but this behavior still occurs in .NET 4.7.