I am working on a program built in MFC.
I have this weird situation when I shake my CFormView. The first time everything is minimised correctly, but when I shake it the second time while all of the windows are restored, one of my CDialog's inside the CFormView are going to the back, but it should be on front.
How can I catch the event of the second shake? What message does it send to my CDialog?
Is it something I can declare on my message map?
I couldn't find anything about it in the internet.
i have found my solution.
i didn't find any message that i could put my finger on, but on my function of "MoveDialog"
I used:
SetWindowPos(&wndNoTopMost,x,y,cx,cy,SWP_NOSIZE|SWP_SHOWWINDOW);
The &wndNoTopMost by MSDN is:
wndNoTopMost Repositions the window to the top of all non-topmost windows (that is, behind all topmost windows). This flag has no effect if the window is already a non-topmost window.
and this is how i have solved my problem!
Thank you!
Related
Hopefully a simple question: I'm making a timer-style application, and I'd like the application to regain focus when the timer ends. The application successfully pops back up when the timer ends, and I can even see a blinking cursor in the first text box, but when I type something it still goes to the app behind it. I've tried every method I could find in the electron documentation (listed below), and none of them work. Is there another avenue I'm missing, or is this just not possible?
Object.values(windows).forEach((window) => { // windows here stores all the application's BrowserWindows
window.focus();
window.focusOnWebView();
window.webContents.focus();
});
app.focus({ steal: true });
Thanks!
I tried all the documented methods as well and nothing really works (at least in Windows 10).
To bring the app on top I have to toggle AlwaysOnTop like this (renderer process):
let currentWindow = window.require("electron").remote.getCurrentWindow();
currentWindow.setAlwaysOnTop(true);
currentWindow.setAlwaysOnTop(false);
but unfortunately it doesn't help with the app focus.
People say that BrowserWindow::restore() function correctly sets focus back to the app. So you might do something like this (although it looks terrible):
currentWindow.minimize();
currentWindow.restore();
It is interesting that I have a similar problem in my other C++ project, so probably it is something OS-related. To solve the problem in the C++ project I had to call SetForegroundWindow function after activating the window. Since ElectronJS BrowserWindow has a getNativeWindowHandle function that returns Windows HWND handle, maybe you could utilize this if nothing else works.
Good luck!
I'm running VS2013 Professional on Windows 7 x64 and often finding that, after a debug session, the yellow tooltips from the debugger don't go away and stay on the screen on top of other windows. For example, the image attached shows a debug tooltip now also showing on top of me posting this question.
I am able to hide it temporarily by pressing Win + d to show the desktop, but as soon as I open / navigate to any window, the tooltip is right back.
The only way I've been able to get rid of these tooltips has been to close and re-open my Visual Studio. Any thoughts about what else I could do?
Try sending the WM_CLOSE message to the tooltip window.
I had hoped to be able to do that with Spy++, but alas you can't send messages from that.
I downloaded SendMessage from StephansTools, this then lets me use the cross hair to select the offending tooltip window and then send the WM_CLOSE message to it.
Caveat: This only seems to work in some circumstances. It's worth a try but may not work every time.
On your screenshot, the tooltip is "this is the next statement that will be executed". This tooltip appears when you hover over a yellow arrow to the left of the code while stepping in debugger (there must be no breakpoint on the current line).
It's quite likely that when the tooltip is stuck, you can un-stuck it by howering over that yellow arrow again, then moving mouse cursor away from it.
As for permanent solution to the problem, I would blame third-party applications that install hooks. Try to temporarily disable whatever such software you have and see if it helps. If you can't figure the exact repro to get the problem, you can simply close any other software you can and do your debugging for a while.
Some typical examples of hooking software:
Input assistance (voice to text, ...)
Automatic keyboard layout correction
Dictionary and language translation
Anything that creates new buttons in other programs
Screenshot software
I have a problem - when accidentally launching any of native Windows apps and alt-tabbing to normal ones, then I have a hint (that occupies a fair quarter of the screen), that I can swipe between apps (screenshot is in Russian, but that's what it says).
The things is that I know for sure that my display is not a touch-screen, so how can I persuade Windows into believing that?
At the moment I have to reboot every time I got it (couldn't find any related process in the task manager to kill).
Thanks.
Actually a reply by #David.
You can move mouse to the upper left corner [to switch between apps], but also makes the swipe hint to hide.
Thanks, #David!
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.
By now everyone writing for Windows probably knows that applications cannot (officially) steal focus from foreground processes, and why. But I have just managed to steal focus, inadvertently, and don't understand how this is even possible.
I have a Delphi app that user brings up with a hotkey (or by a mouse click, or by Alt+Tab), selects a piece of text and hits Enter. My app then minimizes (hides to the tray, even), and pastes the text user just selected into the active window. Nothing new here, plenty of similar projects out there - clipboard extenders, glossaries, macro programs, etc.
What is puzzling to me is that after doing all the above and then sleeping for 1500 ms, I restore my main form and it gets the focus back! It becomes the foreground window, even though it wasn't 1500 ms ago (tested; Windows 7 32-bit.).
In fact, I don't want this at all, so before restoring my main form I record which window has foreground and I give it back to that window after it's been given to me. I'm just curious why my app gets to be in the foreground when by rules it should not. Maybe I don't understand the rules as fully as I thought I did?
If you look at the documentation for SetForegroundWindow you see a list of conditions for the call to succeed, one of them is "The process received the last input event." So if the user does not do anything after pressing enter in your app you still have the right to steal focus. I don't know if Delphi calls SetForegroundWindow for you when the window is restored but it might be something to look into.
I don't know how you restore your window but using SW_SHOWNOACTIVATE with ShowWindow might help...