When my modal ChildWindow closes, the parent control does not get "un-grayed" and all user input is blocked, forcing me to restart the application. Exact scenario which causes this behavior consistently:
ChildWindow A pops up and user clicks a custom button on the bottom of the window (instead of OK or Cancel). My code does some work and then calls the Close() method for the ChildWindow.
ChildWindow A closes and functionality is restored to parent control (controls are un-grayed).
User causes ChildWindow B to pop up. User clicks system-generated OK or Cancel button.
ChildWindow B closes, but the parent controls are still grayed out and inaccessible.
Either of the windows work fine repeatedly on their own. Any thoughts?
I saw something similar (it might not fix your exact problem) and found some discussion about the ChildWindow here
they suggested this method in the ChildWindow Closed event and it worked for me.
Application.Current.RootVisual.SetValue(Control.IsEnabledProperty, true);
Also try calling this.DialogResult = true instead of the Close method.
Related
WPF 4.5
I've got an app where I show a modal Window from my app's main Window by instantiating it, setting its owner to be the main Window, and then calling ShowDialog(). The modal Window has "Topmost=true". The main Window does not.
When I run my app the modal Window shows in front of the main Window, and it is kept in front of the main Window just as expected. However, I can simply click on the main Window behind the modal Window to Activate the main Window and manipulate it...I can even close it!
In my humble opinion this is definitely not the desired behavior for an application with a modal Window. I'm confused as to why WPF handles it this way. More important, I need a solution that will keep the modal Window in front while also blocking access to the main Window behind it (isn't that supposed to be a basic function of a modal Window?)
I believe this desired behavior has always been the default behavior when using ShowDialog in WinForms (way back in the day.) What am I missing here, and how can I get this working with WPF?
You have to set the owner window before ShowDialog :
modalWindow.Owner = RootWindow;
Opening a ChildWindow will automatically apply a blur effect on parent window's textbox, textblock, etc. However, I don't need this effect. is there a way to change it.
I tried the OverlayOpacity and OverlayBrush, nothing works.
I would direct you a previous question that I asked I think the answer I got would also answer your question Leave parent window active when child opens
I have seen similar issues reported but never answered. This is a major problem for me.
I have a WPF application which opens a new window using ShowDialog(). In the new Window I have a datagrid but it could be any type of object. When I handle the doubleclick event of a row I close the window. At this point the window closes but the control in the main window directly under where I clicked recieves the clicks.
I tried handling PreviewMouseButtonDown and looking for clickcount=2 instead of the doubleclick but that had the same effect. I tried setting e.Handled = true and that also had the same effect. I tried setting an owner on the window and no change. I tried modal as well as regular windows and no change. I responded to the PreviewMouseButtonDown for a single click and that worked but I absolutely need this to be a double click.
Problem is double-click event fires on 2nd mouse DOWN event. If you close the window as part of that event-handling, you're still about to receive a mouse UP event in whatever window was open behind the dialog.
I think the solution might be to set a flag during double-click handling and on mouse up, if the flag is set, close the window.
Ok, i had a similiar problem in our project and its somehow related. We never really fixed it, but now i gave it some more thoughts. And my guess is, because you close the window while you are in a progress of handling the input, this input processing is canceled, your window is closed, but the input request it still remains (because it was not handled before) thus your parent window gets to handle it.
So this is of course just a shot in the dark but would explain our problem.
So to give a solution:
You could instead of close the window, set up a Dispatcher Job using lower priority as Input and just close the window there. It should feel the same for the user but should consume the double click.
Again no guaranty it just sounds resonable in my head.
Good luck.
This issue regarding WPF window (XAML application)
I have a two windows one window getting launced from another window.
Both window get into maximized state when gets open
the child window which gets open has a grid on it and we have operation (double click on row click should close the window).
Problem is happening that when we double click on grid row it closes form correctly but if accidently mouse remains in the same position then some operation on previous window gets perform. if mouse point in different location then there is no problem.
I am not able to define this as event bubbling in WPF or routed events.
Could you please advise on this.
I think you should add:
e.Handled = true
This is kind of a hard question to describe, and I've searched for about an hour now to no avail.
Essentially, picture a small 'flyout' window like the Windows 7 Wireless Control or the Volume Slider from the system tray(notification area). When you click on the icon, the application pops up with focus, and if you click off of it, the window destroys itself.
I thought it woudl be easily solved by simply having my window destroy it self when it loses focus (I've been listening for WM_KILLFOCUS), but the problem is, if the icon is clicked, my window does not always get focus. Since this isn't the case, if the user clicks my icon, and then clicks away because it was a mistake (on the desktop say), then how can I set my app to close?
I've tried messing with SPY++ but checking the volume control / wireless control apps are proving difficult as they disappear when I try to get their window/process handles.
Thanks!
The usual way this is implemented is by starting a timer on the window creation. If the window gets the focus before the timer has triggered, this means the user has interacted with the window. In this case, the window will just stop the timer and will destroy itself when it loses the focus. In the case the window did not get the focus before the timer was triggered, the window will destroy itself on the timer event.
This is also usually combined with opacity animation, so that the window is fading out while waiting for the user. Sort of a visual feedback to the user that it will be soon gone. However, the opacity animation is used mostly for notification toasts, and is rarely used for control windows like the volume control.
The alternative is to force set the focus in your window when the user interacts with your systray icon.
Also note that if your window is a top-level window, the preferred message to listen is not WM_KILLFOCUS, but WM_ACTIVATE and WM_MOUSEACTIVATE. You can also listen to WM_NCACTIVATE, but that one has some specifics, if you are doing a custom non-client area.
Update: You can set the focus to your window by calling either SetActiveWindow or SetFocus on it when you create it (or when you make it visible, if you're hiding it).
A long, long time ago I wrote a drop-in replacement for the Windows 3.1 Task Manager that accomplished this by handling WM_ACTIVATEAPP. Give that a try.
Have you looked into the Popup? That one will disappear once you click outside it (unless you set StaysOpen to true).