I have a Windows CE application which logs key strokes of the mobile device. There's a button to initialize the recording functionality, which forces the main window to minimize by calling:
ShowWindow (hWnd, SW_MINIMIZE);
Before minimizing the window, I register to the trigger button event (via a custom API). While the app is minimized I perform some button clicks and press the trigger button to end the session. When I receive the trigger button event, I call:
ShowWindow (hWnd, SW_MAXIMIZE);
The problem is that the window does not get maximized. If I debug the application, I could see that the ShowWindow function is called. I could bring it to the foreground via the TaskManager by switching to the application.
Can someone please explain the cause of this and suggest any solution that I can take?
EDIT:
Solution:
Call "SetForegroundWindow" before calling ShowWindow and use SW_RESTORE instead of SW_MAXIMIZE. SW_MAXIMIZE does not work.
SetForegroundWindow (g_hWndMain);
ShowWindow (g_hWndMain, SW_RESTORE);
Showwindow could fail by several reasons.
You could try:
1) Set foreground
SetForegroundWindow
For WinCE specifically refer to the following MSDN article.
http://msdn.microsoft.com/en-us/library/ms940024.aspx
SetForegroundWindow((HWND)(((ULONG) hwnd) | 0x01) );
2) Bring to front
BringWindowToTop
http://msdn.microsoft.com/en-us/library/ee504610.aspx
Second parameter in ShowWindow(HWND hWnd, int nCmdShow) can take a value:
SW_HIDE, SW_SHOW, SW_SHOWNA, SW_SHOWNORMAL
The last one activates and displays window; it will be restored to its original size and position.
About windows functions in WinCE you can read on MSDN.
Try to first restore window, then maximize.
I don't have Windows CE so can't test, but that should work.
Cheers & hth.,
Related
I used to hide my background app's console window until I needed it with
ShowWindow(console_hwnd,SW_HIDE);
My Windows got an update and switched to "Windows Terminal" as the default console app.
That line of code doesn't work anymore it just minimizes the console to taskbar. What is the proper way to fully hide Windows Terminal?
EDIT:
Please read the question carefully. It says HIDE the console window. NOT remove the console completely. I need to be able to show it again later. Thats the purpose of SW_HIDE and SW_SHOW that are no longer working with the new Windows Terminal.
If you want to show the console at any time, you could hide and show the console by changing the coordinates of the console.
int main() {
HWND consoleWindow = GetConsoleWindow();
SetWindowPos(consoleWindow, 0, -600, -600, 0, 0, SWP_NOSIZE | SWP_NOZORDER);
return 0;
}
EDIT:
According to this document, the second parameter to ShowWindow() might get ignored the first time it is called. Try calling it twice.
ShowWindow(hWnd, SW_HIDE);
ShowWindow(hWnd, SW_HIDE);
In addition, did you run this program as administrator? If so, I suggest you cancel it, since the window is in a higher privileged process, so your call will be ignored.
Hope it helps.
When you have an application hiding in the tray, you should be able to expand it. Here the problem comes in: when I holding tab key to switch focus in taskbar and try to show the window with hWnd->ShowWindow(SW_SHOW) and SetForegroundWindow(*hWnd) calls, my window is not activated. I have the ability to work with it, but it doesn't have focus for the tab key until I click it again (in the tray) without holding the tab.
The problem is that when I call ShowWindow and SetForegroundWindow I get 0 return code from both.
Sample code:
// blablabla working with messages loop
void OnShowTrayWindow(UINT /*message*/, WPARAM /*wParam*/, LPARAM /*lParam*/) {
// handle some situations
m_hWnd->ShowWindow(SW_SHOW); // returns 0 in my case
SetForegroundWindow(*m_hWnd); // returns 0 in my case
SetFocus(m_hWnd);
}
My window have WS_TABSTOP flag in styles. Actually, tab works perfectly when I have activated window.
P.S. I think that this behavior can be related with the SetForegroundWindow requirements (see https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setforegroundwindow)
Is there a way to programmatically hide an application on windows? I want to achieve the same thing as the windows+D shortcut, but for a single application. I want to do this from within that application (application consists of several windows, one of those can't be moved, resized, closed or minimized by the user). Application is written in c++ and uses Qt for the UI.
to do so it's so easy:
1- retrieve the handle to that window:
HWND hChild = GetDlgItem(hWnd, ID_MYCHILD);
2- send to it SW_SHOW either using ShowWindow or via SendMessage:
ShowWindow(hChild, SW_HIDE); // hide
ShowWindow(hChild, SW_SHOW); // show
SendMessage(hChild, SW_HIDE, 0, 0); // hide
SendMessage(hChild, SW_SHOW, 0, 0); // show
if the window doesn't belong to your application then:
1 - retrieve the main window with:
HWND hWnd = GetForegroundWindow(void);
2- use the above to hide/show it
ShowWindow(HwndWindow, SW_MINIMIZE);
Here's the MSDN ShowWindow documentation.
In addition you may find EnumChildWindows useful for finding all these windows if their handles aren't readily available to you.
I'm working on an application to detect a pop-up dialog and then
automatically dismiss it. I'm writing this as a C++/Win32 app. The
dialog box is generated by IE 7 and I can detect the window, but
several methods to get the OK button to "click" have failed.
Doing searches for other people's solutions, sending these messages to
the button handle seems to have worked in a lot of situations:
PostMessage( handle, WM_LBUTTONDOWN, 0, 0 );
PostMessage( handle, WM_LBUTTONUP, 0, 0 );
PostMessage( handle, BM_SETSTATE, 1, 0 );
It has no effect on the button state in my tests though.
I can send tab characters to the main window and see that the OK
button gets focus, but then sending return characters does nothing.
To learn more about this I used Spy++ to get information about the
window hierarchy and what messages are delievered when I manually
click the OK button.
Looking at the message log and reading about WM_MOUSEACTIVATE seamed
to offer a solution. The log info shows that 0002166C was the button
window. So in my code I tried this:
GetClassNameA( handle, str, str_size );
if( strcmp( str, "Internet Explorer_Server" ) != 0 )
return TRUE; // Not the window we're interested in.
// Send a message to activate the button window and have it process a mouse click.
PostMessage( handle, WM_MOUSEACTIVATE, (WPARAM) dialog_handle, MAKELPARAM( HTCLIENT, WM_LBUTTONDOWN );
Based on the window hierarchy and message log, I think the window with
the class name "Internet Explorer_Server" is the button. Maybe I'm
wrong, because it does seem like an odd class name for a button...
Below is a link to the window hierarchy image, message log when I
manually click the OK button. Last is the code that's executed on a 1
second timer ticket, looking for the window.
Any insight and help is appreciated!
Image of the window hierarchy, source, window messages, and test dialog source are available here:
https://sites.google.com/site/matthewmillersmiscellanea/Home/
Ideally, you should create a DLL which exports a Global CBT Window Hook. This would allow you to get early notification when a dialog is going to be created. This would avoid the need to drain resources by constantly polling.
Once you've detected that a dialog is about to be created, you have two options:
1) Prevent the dialog creation.
I don't recommend this, it causes all sorts of problems with code that was fully expecting a valid HWND to be returned by CreateDialog();
2) Asynchronously control the dialog.
We achieved this by using PostMessage with a Registered user message and picking it up by hooking the WNDPROC. When you get this message, then you have to decide how to kill the dialog that you're in.
There are multiple ways to exit the dialog:
a) Simulate pressing OK, Cancel, Abort, No buttons using WM_COMMAND(BN_CLICKED) (as Chris comments). You can use GetDlgItem(), look for the WindowText and make your choice. However, this doesn't work for non-US-English. There may be some distance in leveraging the Accessibility API here though.
b) Simulate closing the dialog with PostMessage(WM_CLOSE, m_hWnd). This doesn't always work as expected - some dialogs have no [X] close button and their client code is expecting a specific button to be pressed instead.
c) Simulate user input using the SendInput() API. This worked around dialogs that had anti-popup-killer code in them :)
Our final solution was a rule+heuristic-based approach that had a configuration file which we could tweak when the app/IE dialogs changed their ID's, class names or parent class names.
To close continually a specific popup given that you know the window class name and window caption
#define UNICODE
#include <windows.h>
#pragma comment(lib, "user32")
int main (int nn, char ** aa)
{
while (true) {
HWND iHandle = FindWindow (L"theWindowClassName", L"theWindowCaption");
if (iHandle > 0) SendMessage(iHandle, WM_SYSCOMMAND, SC_CLOSE, 0);
Sleep (200); // check 5 times per second
}
return 0;
}
if one is not known or too generic (e.g. "Dialog") you can omit it by passing a null
HWND iHandle = FindWindow (L"theWindowClassName", 0);
or
HWND iHandle = FindWindow (0, L"theWindowCaption");
of course this will close all windows with the given names.
HWND button = CreateWindowEx(0, "BUTTON", ...);
SetFocus(button); // Button no get focus! :(
Also, I have other controls on my form that I am able to SetFocus() to.
Thanks, Martin
It has been FOREVER since I've had to do this, but...
Were this a dialog, I would tell you to send a WM_NEXTDLGCTL via PostMessage(). The default dialog item message handler would take care of the rest for you setting keyboard focus and selection activation. However, this is a different case if I read this correctly. You're creating both parent and child windows raw on the fly. If this is the case, SetFocus() to the parent window, and handle WM_SETFOCUS on the parent window by bringing it to top, then setting focus on the child window. WM_SETFOCUS, and WM_KILLFOCUS were designed to allow you to switch the 'activated' state of your controls, and most handle it for you (unless your window is an owner draw control or some such). But in a raw window, when your base parent window is sent the focus, you need to appropriately ensure the proper child has it if you're hosting any (think of it as managing your own 'dialog'). Again, normally this is done by the default dialog procedure for you if this were a dialog, but being raw windows you're kind of stuck managing it all yourself.
Though I can't imagine how, I hope that helped somewhat.
SetFocus is a function, not a procedure. Call it as a function and check its returned value. Either the retuned value is null because you made an error in the CreateWindowEx() call and "button" isn't a valid handle or it's a window not associated with your thread's message queue, or the return value is not null (it's now the prior focused window's handle) and you do have the focus (but are somehow failing to detect it).
Try setting the WS_TABSTOP style on the button.
If you create that button in respond of the WM_INITDIALOG message you should return FALSE to prevent dialog box procedure to change the focus.