Child Window Z-Order Discrepancy (interesting one!)

Toby Sharp

unread,

Apr 24, 1998, 3:00:00 AM4/24/98

to

In the case of overlapping child windows controls:-

The window which appears visually to be on top is the one which has been
drawn last.
This is the window at the bottom (or end) of the window list - the last
child window.
(You can check this with Spy++.)

However, mouse messages (eg. WM_LBUTTONDOWN / BN_CLICKED) go to the child
window at the top (or beginning) of the window list - the first child
window.

So if you have two overlapping pushbuttons, button B looks in front, but
when you click, it actually activates button A.

Try playing around with two overlapping buttons on a test dialog, and
forcing click and paint messages, and you'll see what I mean.

Does anyone know a way to resolve this discrepancy?

Cheers,
Toby.

----------------------------------------------------------
Toby Sharp, B.Sc. (Hons.), G.I.M.A.
Software Engineer

Send your animal-in-pub jokes to:
toby....@aran.co.uk
----------------------------------------------------------

David Lowndes

unread,

Apr 26, 1998, 3:00:00 AM4/26/98

to

>In the case of overlapping child windows controls:-

>...

>However, mouse messages (eg. WM_LBUTTONDOWN / BN_CLICKED) go to the child
>window at the top (or beginning) of the window list - the first child
>window.
>
>So if you have two overlapping pushbuttons, button B looks in front, but
>when you click, it actually activates button A.

Toby,

That's an interesting point you've highlighted. I was aware of the
ordering but not that mouse operation was affected that way. I think
the quirk arises because of the way that ChildWindowFromPoint works -
it is defined to return the first child window that contains the point
- which isn't what you'd expect from a purely visual aspect.

I had an annoying quirk with tooltips and wrote a
ReverseChildWindowFromPoint routine that returned the topmost window
that contains the point. However in your situation it wouldn't be any
help as Windows is doing the detection for you.

Does this cause you some specific problem - perhaps there's another
way around it?

Dave
----
Address is altered to discourage junk mail.
Please post responses to the newsgroup thread,
there's no need for follow up email copies.

Andrew Osman

unread,

May 4, 1998, 3:00:00 AM5/4/98

to

Toby,

I don't think the list of child windows in SPY++ is necessarily in Z-Order.
I think its most likely in creation order. Mouse hits go to the window at
the top of the Z-Order and windows are drawn in reverse Z-Order, i.e. the
window at the bottom of the Z-Order is drawn first, while the window at the
top of the Z-Order is drawn last. What you are seeing visually may be
caused by the fact that you're not using WS_CLIPSIBLINGS which you need to
use when you have overlapping child windows.

--
---
Andrew Osman
ViewSoft, Inc.
http://www.viewsoft.com
---

Toby Sharp wrote in message
<34E691D56386D0118D53006008557C72291B80@ntcomsrv>...

>In the case of overlapping child windows controls:-
>

>The window which appears visually to be on top is the one which has been
>drawn last.
>This is the window at the bottom (or end) of the window list - the last
>child window.
>(You can check this with Spy++.)
>

>However, mouse messages (eg. WM_LBUTTONDOWN / BN_CLICKED) go to the child
>window at the top (or beginning) of the window list - the first child
>window.
>
>So if you have two overlapping pushbuttons, button B looks in front, but
>when you click, it actually activates button A.
>