What could prevent a dialog from being displayed modally in foreground in some circumstances?
A process (KeePass.exe) owns a hidden window. A global shortcut (CTRL+A) displays a dialog in foreground. This is done using the DoModal method. And it works.
However, in some circumstances which I do not know, the follwing happens: The window appears in the taskbar and only after clicking on it, it is shown. I created a plugin for KeePass which overwrites the WndProc and waits for a certain WM_COPYDATA message. If this message arrives, the dialog is shown using DoModal. However, in this case it is only displayed in the taskbar and not shown in foreground.
The WM_COPYDATA message is sent from a different process, but this should not matter right? What can be a reason for that?
I am struggling for so long on this, it's so weird that's even difficult to explain the problem.
I tried issuing SetForegroundWindow(hKeePassWindow) before showing the dialog but no change.
Related
When I click the application shortcut, if the program is already open, I will show the program and enable FlashWindow. (FlashWindow(true);)
After blinking once, the taskbar is highlighted.
Theoretically, clicking on the application window would unhighlight the taskbar.
But it doesn't.
There is no problem when the window is minimized.
But it doesn't work when the window is already displayed.
I tried to get all the window handles of the application based on the process id and activated them one by one, but that didn't work either.
For this step I printed the log and used GetForegroundWindow to confirm that the change did happen.
How to solve this problem?
Is there any other way to make the taskbar blink only once without keeping it highlighted?
I just want to ask what command in Ruby allows you to check if an application made in Ruby or running application is about to be closed? For example, I have an executable file that i ran and I clicked the close button on the window. I want to make a pop up of a dialog that says "you are about to close". Once you pressed the OK button, the window finally closes.
How can you do this in Ruby?
I don't know how things work in Ruby, but in general, on Windows, when a window receives a request to close, its window procedure receives a WM_CLOSE message. This is the place to display prompts to the user. If the app then wants to block the window from closing (because the user wants to reject it, etc), the app can simply skip destroying the window, and not pass the message on to the default message handler (DefWindowProc()).
In the case where the user clicks on the window's close button, or chooses the "Close" option from the window's pop-up system menu, or presses ALT-F4 while the window is in focus, the window receives a WM_SYSCOMMAND(SC_CLOSE) message, and if the message is passed on to the default message handler, the window then receives the WM_CLOSE message.
Take that information and translate it to Ruby as needed.
My MFC application has multiple top level (parented to the desktop) windows, any one of which can host an external application which can launch a modal dialog. Is there a way for one the other top level windows to get a notification when any of the others becomes modal?
My specific problem is that one of the my windows is hosting an embedded PDF viewer and when the user clicks print, only the window hosting the viewer is locked, not the others.
When a modal dialog is shown EnableWindow(FALSE) is called for the parent. It is deactivated now and will not accept any mouse input. Also it will not receive the keyboard focus.
When EnableWindow(FALSE) is called WM_ENABLE with wParam==FALSE is sent to the window.
When your parent receives this message you can call EnableWindow(FALSE) for all your other windows too. Recursion might be a problem here, but you can use a private window message or flags to prevent this.
Before the modal dialog closes EnableWndow(TRUE) is called again and WM_ENABLE with wParam==TRUE is sent again.
I have a set of modeless dialog boxes open, but I can't for the life of me click on one of them get it to appear in the foreground. It gets focus, but the dialog boxes forever remain in the order on the screen that they were created. The last one created is always in the foreground, obscuring (or partially obscuring) the others.
I have tried:
SetActiveWindow(hDlg);
SetForegroundWindow(hDlg);
SwitchToThisWindow(hDlg, FALSE);
in response to a WM_LBUTTONUP message, but though they get called they do nothing. I have tried different configurations in the dialog box properties like playing with the 'SetForground' or 'Topmost' parameters and they do nothing.
Am I trying to do an impossible task?
What is causing this is window ownership. An owned window is always shown above its owner. This is described in the documentation.
Clearly you have ownership relationships between your modeless dialogs. You can resolve this by making each of the modeless dialogs be owned by the same window.
Exactly how you do about controlling ownership depends on how you are creating these dialogs. If you are using CreateDialog then the third parameter is used to specify the dialog's owner.
Normally when creating a sub window (WS_POPUP), the child window will become activate and the parent will become deactivated. However, with menus, both remain active. At least I am assuming the menu is active, it at least has focus.
Example: Click on the file menu in notepad, the menu appears, yet the notepad window still looks active.
Is it possible to mirror this behavior with either a window style or responding to a particular message?
Thanks
Another example: Combo boxes seem to show a subwindow, yet do not deactivate the window. And you can click on that subwindow, while still maintaining an activate main window. Any ideas on how to grab the class /style of that window?
The list dropdown in a combobox is a bit of a hack, it is both a popup and a child window, I can't recommend that approach (Undocumented style combination, and IIRC, it is a bit buggy to do this with a "normal" floating window/toolbar)
This leaves you with two options:
WS_EX_NOACTIVATE (Main window will stay active, floating window is not active)
Handle activate messages (Both windows will look active)
I am surprised that creating a new popup window activates it. Normally you'd need to call SetActiveWindow. However check out WM_ACTIVATE and WM_NCACTIVATE on how to stop the window becoming deactivated.
A fact that a lot of people miss is that windows does not have a separate window manager component :- most of the window management duties are performed by each window - usually in DefWindowProc.
Most window positioning and activation / de-activation is done - ultimately - via a call to SetWindowPos - which always sends a WM_WINDOWPOSCHANGING message allowing the window to have a final say on what happens.
DefWindowProc also activate its own window in response to mouse clicks and so on.
The result of all this is, it is quite possible to create windows that never accept activation - it does require an extensive understanding of what messages and situations might have led to an activation.
Ultimately I can say that it is VERY handy to have a debugging setup configured for remote debugging - so that you can interact with your debugger without effecting the activation state of the system - and hence drop a breakpoint into the window in questions WM_ACTIVATE handler and simply debug any situation leading to an unwanted activation.
If You want to handle keyboard focus as well, it might be trickier - normally focus is given to an activated window - but again its usually the DefWindowProc responsible for assigning both. I just see it dangerous as having one window, still obviously activated, and another with focus. This will confuse any assistive software greatly.
I'd be tempted to perform a message loop level message hook - Similar to IsDialogMessage - to filter keystrokes intended for the popup window.
If you create your popup window with WS_EX_NOACTIVATE it will not be activated by user input (You could still activate it programatically) and therefore your main application window will still remain active.