I'm doing Surface Automation of an application. The Automation is asynchron. Sometimes, a Dialog window occures and locks the mainwindow for further Access.
I'm using C++ / Win32API, C# or VB. I can get the main window by the processID and want to find (or write) a function, giving me true or false if the main window is locked by an unexpected Dialog window.
Modal windows disable their owner windows. So you need to call IsWindowEnabled on the main window.
Related
Any way to keep debugged program window open while stepping the code in ollydbg? The program displays buttons in a loop in a dialog box. But its window stays minimized so I can't observe what effect each command has on visual display.
source: https://legend.octopuslabs.io/sample-page.html (tutorial 16A)
Since you are debugging this program, the program will be "stuck" before GUI components initialized and enter the main loop of GUI thread. You can just keep all window away of "hovering" the program's window, for example don't maximize your OllyDbg window.
To access and control a window, dialog or popup with Autohotkey the title of that specific window is needed. For some windows the title can be read directly if its visible, but some windows hide it. The window class and the exe (ahk_class and ahk_exe) aren't visible at all. How to gather this information reliable?
Use the Window Spy tool, which is installed together with AHK, it can be started various ways:
Right click the tray icon of a running AHK script and select Window Spy
Start the AU3_Spy.exe in the AHK installation folder
Use the Windows search to search for Window Spy
You will get a window called Active Window Info with various infos about your current active (topmost) window. The first box is the one you need.
Example
The box gives title, class and .exe to detect the target window of which every line can be used to identify the window. Now you should activate the window you want to address and copy the information.
Hint: You can (un-)freeze the display with Win + A
Using Qt 5.3.0 and Windows 8.1:
Don't know if I'm missing something or if this is an oversight in Qt, but when I simply have a QMainWindow that opens a QDialog (with exec()) and then try to use the 'Close window' function of the right-click menu of the Windows task bar icon (while the dialog is still open), the application is not closing as expected, but nothing happens. I also do not get a closeEvent in the QDialog or the QMainWindow.
When only the QMainWindow is open, the application is closed successfully and I'm also getting a closeEvent.
This is actually also reproducible when e.g. using Qt Designer and opening an additional dialog and then trying to use the 'Close window' function.
Any ideas how to fix this behavior?
The behavior you're seeing is not really surprising. In fact, it's exactly what happens with a (mostly) well-behaved Windows app like Notepad, so I'm not sure I'd even call it a bug.
Open Notepad, and select Help->About to get a modal dialog. Now choose Close from the task bar icon. Nothing happens.
The Close from the task bar is sent to the main window as if the user had selected the Close option from the "system" menu. That arrives as a WM_SYSCOMMAND with SC_CLOSE. If you don't handle that explicitly, then DefWindowProc turns it into a WM_CLOSE message, which most main windows handle.
But if you have a modal dialog open, the main window is disabled and thus doesn't get the message.
One way to fix it would be not to have modal dialogs and instead simulate modality with modeless dialogs. That would allow the main window to receive and respond to the message. But that would be a lot of work for a small fix.
If you call your QDialog via QDialog::show() passing the MainWindow as parent ( QDialog *dialog = new QDialog(this) ) where this is the pointer to your MainWindow, it will work. However the dialog won't be modal anymore. I don't know if modality is important in your case.
I've been researching popup menus (see https://msdn.microsoft.com/en-us/library/windows/desktop/ms647626(v=vs.85).aspx) and a bit confused at what they are behind the scenes.
They act partially like windows, but look like controls. For instance, they pop up above other elements, steal focus, and can go outside their parent container which makes me think they are a type of window. But they pass back an HMENU handle instead of a window handle, and they have no title bar, nor handles, nor show up in the task bar.
If they are a type of control, how can they go outside their parent window?
If they are a type of window, can I use window-specific functions on them? or if they are a control in a new window, is there a way to get a win handle to that new window?
Can I get the location of the popup menu for another application?
Found the answer:
trying to get a handle to a context menu in c++
Looks like a menu is a type of window, that is a child of the desktop window. You can get its window handle with EnumChildWindows on the desktop WinHandle and look for the class name of #32768.
There's more about these reserved system windows here:
About Window Classes | System Classes
A popup menu is a menu, not a window.
A menu merely uses a window for display. A new window is created each time the menu is displayed, and is destroyed afterward. By contrast, the same HMENU can be used to display the menu many times.
I have three executables compiled from Visual C++ using OpenGL libraries. Though nothing is different between them in how the window is created, one of them automatically has focus when I run it and the other two require the user to click on the window before they are given focus.
I'm building a WIN32 application as a menu to run the different .exe files, and in here I'm using all the usual suggestions to attempt to focus the windows (SetFocus(hWnd) SetActiveWindow(hWnd)), but to no avail.
Any advice?
What you want is actually SetForegroundWindow (...), because in addition to setting the active window, this will bring your application into the foreground.
SetActiveWindow (hWnd) will only accomplish what you want if your application is in the foreground, it is useful if you have a multi-document application and want to switch between windows.
Here is a relevant selection of code that I use in my Win32 window management system when initializing / resizing a rendercontext:
ShowWindow (hWndRender, SW_SHOW);
SetForegroundWindow (hWndRender);
SetFocus (hWndRender);