Topmost windows cause trouble
Andrew Duncan
ones need to be style WS_EX_TOPMOST. I started out creating these
windows with no parent window, so that when I minimize the main window
they would stay open.
But this apparently means that the subsidiary windows appear in the
Applications list of the NT Task Manager. Some clients complained that
this was inappropriate; and further claimed that the extra
"applications" put a load on the CPU. (I don't believe this, but that's
another story.)
So I changed CreateWindowEx() parameters to make the main window the
parent of the subsidiary ones. (Note that the subsidiary ones are not
embedded in the main window, they are free-floating.) This creates many
strange phenomena when the main window is minimized or in the background
and the subsidiary ones are visible. For example, minimizing the main
window also hides any subsidiary windows. Subsequently created
subsidiary windows are visible, however. If a subsidiary window is
visible, the taskbar icon for the minimized main window goes to its
"pressed" state; clicking it won't bring the main window back.
(Right-clicking and choosing "restore" will.) If the main window is
visible but not active, modal dialogs created by it appear *behind* it.
First: this appears to be standard Win UI behavior. Why? Can anybody
point me do documentation on Win UI conventions?
Second: any way to get desired behavior -- i.e. subsidiary windows that
don't appear in Task Manager Applications list but also function
more-or-less on their own, without their visibility being tied to that
of the main one?
Andrew Duncan
adu...@expertcity.com
Harold Weissfield
WS_EX_TOOLWINDOW style, or create a hidden window to be the parent of the
subsidary windows. If you really want to be fancy, you can use the ITaskBar
interface, but that's overkill for almost all tasks.
Regards,
Harold Weissfield
"Andrew Duncan" <adu...@expertcity.com> wrote in message
news:38E1425E...@expertcity.com...
[snip]
Chris Becke
> My program has a main window and some subsidiary ones. The subsidiary
> ones need to be style WS_EX_TOPMOST.
I would contest that they possible don't "need" WS_EX_TOPMOST. Unless they
are specifically required to be available when other applications have the
foreground.
> I started out creating these windows with no parent window, so that
> when I minimize the main window they would stay open.
hence WS_EX_OVERLAPPED so they stay above your *own* app window?
> But this apparently means that the subsidiary windows appear in the
> Applications list of the NT Task Manager.
See the dox for WS_EX_TOOLWINDOW.
> Some clients complained that this was inappropriate;
I would agree :)
> and further claimed that the extra "applications" put a load on the CPU.
> (I don't believe this, but that's another story.)
Clearly rubbish.
> So I changed CreateWindowEx() parameters to make the main window the
> parent of the subsidiary ones. (Note that the subsidiary ones are not
> embedded in the main window, they are free-floating.)
Standard popup type windows then. They should have the WS_POPUP style.
> This creates many strange phenomena when the main window is minimized
> or in the background and the subsidiary ones are visible. For example,
> minimizing the main window also hides any subsidiary windows.
This is "normal" behaviour for windows with the WS_POPUP style.
> Subsequently created subsidiary windows are visible, however.
hmmm. WS_POPUP windows hide themselves when they notice their parent being
hidden. And show themselves when the parent is shown. DefWindowProc manages
theis behaviour when it notices that the style of the winow its handling a
message for is WS_POPUP.
> If a subsidiary window is visible, the taskbar icon for the minimized
> main window goes to its "pressed" state; clicking it won't bring the
> main window back.
The pressed state of the button is a shell feature - if one of the
applications windows is visible then the application is visible.
The window not being shown is or might be a DefWindowProc feature - The
shell posts an application that must be restored a WM_SYSCOMMAND message
with the code SC_RESTORE. If there is an active popup window then
DefWindowProc tends to forward the message to the active popup, resulting in
the parent not being shown.
Check if your main window is getting a WM_SYSCOMMAND, SC_RESTORE from the
shell when the button is clicked. If it is, then handle that command
manually, and call ShowWindow on your frame window to restore it.
> (Right-clicking and choosing "restore" will.) If the main window is
> visible but not active, modal dialogs created by it appear *behind* it.
erm, parenting sounds screwed - these modal dialogs are the old style ones
with NULL hParents?
> First: this appears to be standard Win UI behavior. Why? Can anybody
> point me do documentation on Win UI conventions?
In the MSDN Library, and available as a book from MSPRESS is a book called
Windows interface guidelines for software design. Which doesn't explain
DefWindowProcs or code level behaviour at all, just how things should appear
to the user - implementation of behaviour is left as an excercise to the
reader...
http://www.mvps.org/user32/rc/defproc.zip has the windows 3.1 "source" for
DefWindowProc. As a lot of the behaviour you note is related to
DefWindowProc you may find something of use in there.
> Second: any way to get desired behavior -- i.e. subsidiary windows that
> don't appear in Task Manager Applications list but also function
> more-or-less on their own, without their visibility being tied to that
> of the main one?
WS_EX_TOOLWINDOW is intended as a hint to the shell not to show a window as
an application window.
WS_OVERLAPPED windows should not hide themsleves when their parent is hidden
(as WS_POPUP windows do).
If all else fails, the hide/show behaviour of owned windows when their
parent is minimised / restored depends of DefWindowProc being given certain
messages. Find out what messages are causing "deciation" from your ideal
behaviour and filter them.
owned windows that are shown while their parent is hidden will display
visible by default. This behaviour is intentional, but goes against the
hide/sho behaviour noted when the parent is minimized and restored. You will
need to manually insert a check on the parent windows visible state, and
show or not show the popup as appropriate.
Chris
--
VisualC++ & Win32 FAQ: http://www.mvps.org/vcfaq
My Win32 Page: http://www.mvps.org/user32
Vince
the EX style WS_EX_TOOLWINDOW. On the other hand, if the tool window
style does not meet your cosmetic requirements (title area too small), you
may create a hiden window and make that window the owner of your
subsidiary windows; those will now have the WS_OVERLAPPEDWINDOW
style bit set. No EX style needed.
Vince
P.S.: here's an excerpt of Win32 Q & A found in VS6 MSDN CD:
Q. I'm writing a wizard-like application that leads the user through some
setup tasks. Since I spawn this application from my main application, I don'
t want the system's taskbar to show a button for this window. I've performed
many experiments and I can't seem to figure out what rules the taskbar uses
to determine whether it should show a button for a window. What are the
rules?
Karen Fries
A. The rules the taskbar uses to decide whether a button should be shown for
a window are really quite simple, but are not well documented. When you
create a window, the taskbar examines the window's extended style to see if
either the WS_EX_APPWINDOW (defined as 0x00040000) or WS_EX_TOOLWINDOW
(defined as 0x00000080) style is turned on. If WS_EX_APPWINDOW is turned on,
the taskbar shows a button for the window, and if WS_EX_ TOOLWINDOW is
turned on, the taskbar does not show a button for the window. You should
never create a window that has both of these extended styles.
You can create a window that doesn't have either of these styles. If a
window has neither style, the taskbar decides to create a button if the
window is unowned and does not create a button if the window is owned.
One final note: before making any of the above tests, the taskbar first
checks to see if a window has the standard WS_VISIBLE window style turned
on. If this style bit is off, the window is hidden; the taskbar never shows
a button for a hidden window. Only if the WS_VISIBLE style bit is on will
the taskbar check the WS_EX_APPWINDOW, WS_ EX_TOOLWINDOW, and window
ownership information.
------
"Andrew Duncan" <adu...@expertcity.com> a écrit dans le message news:
38E1425E...@expertcity.com...
> My program has a main window and some subsidiary ones. The subsidiary
> ones need to be style WS_EX_TOPMOST. I started out creating these
> windows with no parent window, so that when I minimize the main window
> they would stay open.
>
> But this apparently means that the subsidiary windows appear in the
> Applications list of the NT Task Manager. Some clients complained that
> this was inappropriate; and further claimed that the extra
> "applications" put a load on the CPU. (I don't believe this, but that's
> another story.)
>
> So I changed CreateWindowEx() parameters to make the main window the
> parent of the subsidiary ones. (Note that the subsidiary ones are not
> embedded in the main window, they are free-floating.) This creates many
> strange phenomena when the main window is minimized or in the background
> and the subsidiary ones are visible. For example, minimizing the main
> window also hides any subsidiary windows. Subsequently created
> subsidiary windows are visible, however. If a subsidiary window is
> visible, the taskbar icon for the minimized main window goes to its
> "pressed" state; clicking it won't bring the main window back.
> (Right-clicking and choosing "restore" will.) If the main window is
> visible but not active, modal dialogs created by it appear *behind* it.
>
> First: this appears to be standard Win UI behavior. Why? Can anybody
> point me do documentation on Win UI conventions?
>
> Second: any way to get desired behavior -- i.e. subsidiary windows that
> don't appear in Task Manager Applications list but also function
> more-or-less on their own, without their visibility being tied to that
> of the main one?
>
> Andrew Duncan
> adu...@expertcity.com