views:

101

answers:

4

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?

A: 

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.

Stephen Nutt
Most likely im doing an SW_SHOW, rather than a SW_SHOWNOACTIVATE. But with that, I have some other questions if you don't mind. Do you know off hand if you can have focus in a window that is not activated (ie: if a user starts using the keyboard, i would want up/down to work just like it does in a normal menu)? Or if you can prohibit a click activation?
Bob
I can't say I've done this, but I am interested in how this turns out. Try using Spy++ and examining the messages when a menu is displayed.
Stephen Nutt
A: 

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.

Chris Becke
A: 

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.

Chris Taylor
+1  A: 

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)
Anders
Your link looks appealing. I was thinking about going down the tool window approach last night, but didn't realize that their activation didn't come for free.
Bob
Your link was exactly what I needed. Thank you very much.
Bob