I have a TimerProc which calls MessageBox. I want the MessageBox to stay on top of other windows. So for example, the parent window sets the timer, then I move another window on top of that. When the timer fires, I want to MessageBox to appear on top of the window that is covering the app. Is this possible, and how should I go about doing it?
I think you want to make it System Modal as MB_SYSTEMMODAL as described here.
And/or make the window that is on top be the owner of the MessageBox.
Do you need the same message box which is already open to go to the top? Or a new one to open up above the other windows?
If you want the same MessageBox which is already open just brought to the top:
I think you can get a MessageBox window handle if you use EnumThreadWindows but I've never tried it myself. So if that works you could use its window handle in a call to BringWindowToTop.
If getting the MessageBox handle isn't working for you, you can simply create your own window which looks like a message box instead and then call BringWindowToTop instead.
If you want to popup a new MessageBox on the top:
If you want a new MessageBox each time you can use the MB_SYSTEMMODAL flag as described in the MessageBox documentation. MB_TOPMOST is said to be ignored in Vista and above.
Related
I open an open file dialog using GetOpenFileName function. I'm making a handler function that will center the dialog window inside the owner window. I center the dialog on CDN_INITDONE notification.
Currently, it seems that Windows remembers last dialog position for desktop apps and overrides my dialog coordinates. How to reset that last remembered position so that I can check centering will work for my users?
I thought about running a test using a different user or virtual machine but this isn't very convenient. Unfortunately, searching in the registry for myexecutable.exe returns nothing.
I'm running Windows 8.
I'm about a year late, but I just had to deal with this issue. What worked for me was supplying an OFNHookProc to GetOpenFileName(), then subclassing the parent of the HWND passed to the OFNHookProc.
After subclassing, I handle WM_WINDOWPOSCHANGED, and if the coordinates aren't where I think they should be, I do a SetWindowPos(), undo the subclass and return 0.
Edit: I should say that other methods, such as WM_INITDIALOG in the hook proc or CDN_INITDONE did not work for me whatsoever.
So, I have a dialog based application using pure WinAPI. There is a main dialog, and then multiple other dialogs that are toolwindows. These toolwindows are meant to free-float around, the user can drag them, hide them, and show them, but they have no taskbar entry. This is what I intended, but the problem is, when I switch from the main window to a different application, then click on the taskbar entry for the main window, the main window will show up, but the toolwindows will not. They stay hidden behind the main window and sometimes windows of other applications, and you cannot use them until you move all of the top-most windows and hunt down the toolwindow.
So, what I'm trying to do to work around this is, when the user restores the window from being minimized, I want to enumerate through all of the tool windows and bring them to the front, maybe by calling SetActiveWindow().
But what message gets sent when the window is restored? I was thinking WM_SHOW, or WM_RESTORE, but they don't exist.
Another question, and if you answer this the first question is irrelevant because I will no longer need to use that workaround: Is there a better method of bringing all tool-windows to the front?
Give the tool windows the WS_POPUP style (and not WS_OVERLAPPED), and make the main window their parent (strictly it is their owner window). That way the tool windows will remain on top of the main window. This may (or may not) be what you want.
The naive answer to the question is to listen to WM_SIZE and respond to a wParam value of SIZE_RESTORED.
The other obvious possibility is to make all the tool windows be owned by the main window. So long as you are happy for the tool windows always to be on top of the main window, this will solve your problem. The owned windows will be hidden when the owner is minimized, and re-shown when the owner is restored.
Learn more about ownership in the MSDN topic on Window Features.
I have other application's fullscreen direct-x window, which I need to hide. I found the way to hide it by hooking direct-x create device and changing window parameters so it is not fullscreen. This works ok on XP but on Win-7 I can't use any other application because it looks like application is switching it to be foreground window so all clicks and keyboard input goes to that window. However if I click fast I can make some action. This make me think that this app is using some function to direct input to itself, or to focus, dunno what.
The other thing is that if I resize the window and don't hide it, all works ok.
I tried to hook SetCapture, SetForegroundWindow, SetActiveWindow and SetWindowPos and none of this helped.
Do you have some idea how can I hide window in other way, or what can cause this focusing to invisible window?
I have a program with many windows open. I want all windows to be visible, but only one window can be interactable, until a certain event has occured. e.g. pressing a button.
At the moment, I can still click another window, and interact with it, how do I only allow interaction with ONE window, until a certain event occurs?
Imagine this as the program:
I want only the frontmost Window to be selectable, if I try to select any of the other windows behind it, it should not work.
Does anoybody know how to do this?
Thanks!
Michael
It sounds like you want a modal window.
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.