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.
Related
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.
I've uploaded a VS2010 project at the below location. This test app should be run once you have a full screen application running. As soon as its running, you have 2 seconds to click back on your fullscreen application. It creates 2 modeless dialog boxes using the full screen application (which should be the last window to have focus) as the owner of the dialog boxes. One dialog is displayed, hidden, the second dialog is displayed, hidden and then the first dialog is displayed again in a cycle. What I find is that when the first dialog box is displayed for the second time, the taskbar pops up. I've spent 4 painful days trying to understand whats going on here and I am desperate for some help.
I received some help which suggested that when I call DestroyWindow to hide the dialogs, Windows would put focus "somewhere" - and in my case the taskbar. Previously when I asked this question I wasn't using the full screen application as the Owner of my windows. I would have thought that the focus should go back to the owner window? I have also tried calling SetFocus() and SetForegroundWindow() on the full screen application prior to calling DestroyWindow on my dialog - but the seems to cause the taskbar to appear everytime and I don't want that at all.
Please help!
Sample VS2010 Project
Is there a way to change the position of the popup menu. With top-level windows I can do it by CBTProc Callback Function and MoveWindow. Can I do the same with menus? Needs to be done so that the pop-up menu is located only in the area of its parent window. Something like a light window manager.
Yes, in a WH_CBT hook callback, you'll be notified with an 'nCode' of HCBT_CREATEWND whenever a menu window is created. Test for the class name, standard menu/submenu windows would have a class name of '#32768'. You can then send a MN_GETHMENU message to the window to find out which menu is about to be activated. But as documented, it is too early to move the window when the notification is received, the menu is not even visible yet, so you might need to sub-class the window and process additional messages.
Note that you don't need a hook to be notified when a menu window is shown, you can put a handler for the WM_ENTERIDLE message, test for 'wParam' to see if a menu caused the message, get the menu window from 'lParam' and again send a 'MN_GETHMENU' to find out the specific menu. It is possible to move the window at this point without further message handling. Just be aware that 'WM_ENTERIDLE' will be called multiple times so you need to keep track of you've already moved a particular window or not.
I have a VB6 ActiveX exe that is launched from a third-party CRM App. On launch, the main form opens but it starts to flash and then loses focus. If you move the form, you'll see a server busy screen with the Switch To, Retry button.
I've tried using SetFocus and the SetFocusAPI in the OnActivate event of the form, but that doesn't work. Are there any suggestions on how I can have this form have focus when launched from the other app?
Additional Info:
The OnLoad event calls the SetWindowPos API in order to center the app over the calling app and sets HWND_TOPMOST.
Additional Info:
The Active Window is the correct window(but it's clearly not in focus)
The foreground window is the calling application. SetForegroundWindow switches the foreground window, but immediately returns back to the calling app. It's not until I click on the form that the form is in the foreground. I'm attempting all of this within a loop in the module that calls the form (and not in the calling app).
The CRM application has to call AllowSetForegroundWindow to "authorize" the ActiveX ProcessID to "steal" the focus from the current process.
Have you tried setting the tab order on the form? Your user control should have a tab order of 0 so it gets the focus.
Also, where does the focus go after it is launched?
I want to be able to interact with main window of applications like Firefox or Word, while modal window is active.
What I mean by interact is to:
Copy text
Move window
Close window (by pressing x button)
Are these possible under Windows environment?
No, the modal windows hide the parent's messaging loop so no events get processed by them.
If you want to do it programmatically, you can. SendMessage will invoke the target window's message handler when the target isn't expecting it, so you'd better be very careful what you do.
If you want to do it as a user, operating the mouse and keyboard, then your question belongs on a different web site even though Blindy answered that question for you.