I have a normal window, and I want to add a button, which can be pressed in my window when it's inactive, and this won't steal the focus from the currently active window.
Example: Touch keyboard button in the system taskbar of Windows 8/8.1/10, this one:
Please note an active application is still active when this button is clicked, but the focus goes to the taskbar when its empty space is clicked.
Classic solutions:
To make a whole top-level window non-activatable, WS_EX_NOACTIVATE ex-style can be used. Unfortunately, this style causes a lot of problems with top-level windows, and it cannot be applied to child windows.
Commonly recommended approach is to listen to WM_MOUSEACTIVATE message and answer MA_NOACTIVATE in case the control was clicked. This works, but only partially: The window won't be activated during the clicks, but the previously active window loses the active state, and GetForegroundWindow returns 0. This can be solved by remembering the last active window (either by periodical polling, or by monitoring EVENT_SYSTEM_FOREGROUND or HSHELL_WINDOWACTIVATED / HSHELL_RUDEAPPACTIVATED), and by forcibly restoring it. A lot of headache actually.
Win7-way:
Since Windows 7, there's a new undocumented API-function SetChildWindowNoActivate, with ordinal 2005 in user32.dll. It can be declared like this (Delphi-style):
function SetChildWindowNoActivate(ChildWnd: HWND): BOOL; stdcall;
external 'user32.dll' index 2005;
This function is used in Windows 8/8.1/10 to make no-activate buttons like Touch keyboard, Virtual touchpad and Language switcher.
Here's a screenshot of a sample application with a pushed no-activate button and an active Explorer window above it:
Related
When a focused window is closed, Windows will typically set focus to a different window when possible. I'm trying to figure out what exactly causes this to happen, and in what scenarios does this not occur.
I'm noticing that when some windows are closed, they do not cause the OS to set focus to a new window (eg. Discord, Slack). Discord and Slack are both hidden instead of destroyed on close, but then there are also other windows that when hidden will still cause the OS to set focus to a different window. One such example is with a fresh WPF app and changing the window's Visibility to Collapsed - this causes the window to be hidden, not destroyed, and yet the OS reassigns focus to another window.
What causes some windows when hidden to reassign focus (eg. WPF collapse)? As opposed to applications like Discord/Slack, which are hidden, yet do not reassign OS focus.
It's a multi-step dance of message exchanges, and I no longer have all the details cached in my head. So, generally speaking ...
There's a distinction between activating a window and setting the focus to a window. Windows can get activated in various ways, including a mouse click (either in the client or non-client areas, a keyboard operation, a window being created by a process that currently has "the foreground love", etc.)
A window that's activated can (in effect) accept the focus, reject the focus, or direct the focus to another window (such as a child window like an edit control or button).
A window that doesn't make the effort to direct the focus explicitly when its activated will (likely) end up with the focus by default. That's mostly an artifact of how DefWindowProc handles the relevant messages. But if it's using the dialog manager, then the dialog manager will (if I recall correctly) set the focus to one of the child windows that has the WS_TABSTOP window style.
Imagine a simple text editor application that has a top-level window and one child window that fill the top-level window's client area and hosts the actual editor functionality. In normal behavior, the child window would have the focus whenever the application is in the foreground. But if the top-level window is activated (for something other than a mouse click in the child window's client area), and the top-level window fails to redirect the focus to its child, then it may appear as though nothing has the focus because the window that does have the focus doesn't respond to most kinds of keyboard input.
Key messages involved include: WM_ACTIVATEAPP, WM_NCACTIVATE, WM_ACTIVATE, WM_MOUSEACTIVATE, WM_SETFOCUS, and WM_KILLFOCUS.
Edited to emphasize
what causes the OS to re-assign focus from a window?
In most cases, the OS does not assign focus. It activates and deactivates windows, and the affected applications respond to those events by setting the focus. Applications have a lot of flexibility in how to respond. So if there's an anomaly in where the focus is, it may be more of a question about the behavior of individual applications than about Windows.
It's also possible for a window to have focus but for it to seem as if no window has focus. One case is where the top-level window has focus but doesn't react to the keyboard itself because focus is normally supposed to be assigned to one if its child windows. It's also possible for a hidden window (at least a hidden child window) to have focus if it's not disabled.
Win32's DefWindowProc and dialog-specific APIs, MFC, WPF, and other frameworks generally provide "standard" behavior for handling focus and activation in common cases. But there's a lot of nuance, and there are inherently some differences. For example, WPF applications (if I recall correctly) use windowless child controls, so the traditional behaviors have to be implemented by the framework.
Why does the mouse cursor disappear when typing inside a notepad.exe or wordpad.exe or run.exe window? Which function/interrupt/etc is responsible for that? Typing in, for example, a web browser or cmd.exe does not result in the cursor disappearing. Which Win API functions in machine code display the mouse pointer and how (including software and hardware) and how this disappearance is low-level performed?
Hiding the mouser pointer while the user is typing can be voluntarily implemented by an application. Few applications do so.
Typically, you would implement it by handling Win32 API notifications:
Hide the pointer on WM_KEYDOWN
Show the pointer on WM_MOUSEMOVE and many, many more events such a menu and window related events.
Furthermore, applications should only hide the mouse pointer if Hide pointer while typing is checked in the mouse pointer options (see below).
This option can be queried using the SystemParametersInfo() WIN32 API function passing SPI_GETMOUSEVANISH (aka Mouse Vanish feature).
If my wxWidgets application creates a new window while the application does not have focus, its taskbar icon blinks yellow until I switch to it, as shown here:
This is annoying. How can I prevent this from happening?
EDIT: The original version of this question suggested the blinking was happening during startup. After further investigation, this is not occurring right at application startup; rather, it occurs if I create an additional window while the application does not have focus.
To give a bit more background: my application is a sort of server, that opens windows in response to network events. If I boot up the application, then switch focus to something else and a network event comes in while the focus is elsewhere, my application will open a new window in the background (not grabbing focus) and this blinking will occur.
The windows are wxFrames; the application constructs them and their child widgets, then calls Show(true) on the frame.
Also, I've attempted to set a breakpoint on the FlashWindow Win32 API function, hoping to trap wherever in WX it's getting called, but haven't been able to make that work.
Maybe the following would work:
wxTopLevelWindow::ShowWithoutActivating ( )
http://docs.wxwidgets.org/trunk/classwx_top_level_window.html#a03e526f505716568318d601318527bd0
Yes. If you create a new top level window while the app does not have focus, then the task bar icon will flash. This is the intended behaviour of the windows operating system.
Normally when creating a sub window (WS_POPUP), the child window will become activate and the parent will become deactivated. However, with menus, both remain active. At least I am assuming the menu is active, it at least has focus.
Example: Click on the file menu in notepad, the menu appears, yet the notepad window still looks active.
Is it possible to mirror this behavior with either a window style or responding to a particular message?
Thanks
Another example: Combo boxes seem to show a subwindow, yet do not deactivate the window. And you can click on that subwindow, while still maintaining an activate main window. Any ideas on how to grab the class /style of that window?
The list dropdown in a combobox is a bit of a hack, it is both a popup and a child window, I can't recommend that approach (Undocumented style combination, and IIRC, it is a bit buggy to do this with a "normal" floating window/toolbar)
This leaves you with two options:
WS_EX_NOACTIVATE (Main window will stay active, floating window is not active)
Handle activate messages (Both windows will look active)
I am surprised that creating a new popup window activates it. Normally you'd need to call SetActiveWindow. However check out WM_ACTIVATE and WM_NCACTIVATE on how to stop the window becoming deactivated.
A fact that a lot of people miss is that windows does not have a separate window manager component :- most of the window management duties are performed by each window - usually in DefWindowProc.
Most window positioning and activation / de-activation is done - ultimately - via a call to SetWindowPos - which always sends a WM_WINDOWPOSCHANGING message allowing the window to have a final say on what happens.
DefWindowProc also activate its own window in response to mouse clicks and so on.
The result of all this is, it is quite possible to create windows that never accept activation - it does require an extensive understanding of what messages and situations might have led to an activation.
Ultimately I can say that it is VERY handy to have a debugging setup configured for remote debugging - so that you can interact with your debugger without effecting the activation state of the system - and hence drop a breakpoint into the window in questions WM_ACTIVATE handler and simply debug any situation leading to an unwanted activation.
If You want to handle keyboard focus as well, it might be trickier - normally focus is given to an activated window - but again its usually the DefWindowProc responsible for assigning both. I just see it dangerous as having one window, still obviously activated, and another with focus. This will confuse any assistive software greatly.
I'd be tempted to perform a message loop level message hook - Similar to IsDialogMessage - to filter keystrokes intended for the popup window.
If you create your popup window with WS_EX_NOACTIVATE it will not be activated by user input (You could still activate it programatically) and therefore your main application window will still remain active.
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.