RE: [XaraXtreme-dev] Problem in wxWidgets 2.6.3...

["Gerry Iles" <GerryI@xxxxxxxx>]

Indeed, that is what it is trying to do.  I'm not convinced it always
works correctly though because of the comment in ChildWindowFromPoint
that says:

    // Go backwards through the list since windows
    // on top are likely to have been appended most
    // recently.

The windows really need to be tested in strict top-first order for it to
work correctly.  I don't like the sound of that "likely"...

Gerry

-----Original Message-----
From: owner-dev@xxxxxxxxxxxxxxxx [mailto:owner-dev@xxxxxxxxxxxxxxxx] On
Behalf Of Alex Bligh
Sent: 19 May 2006 14:27
To: Alex Bligh
Cc: dev@xxxxxxxxxxxxxx; Alex Bligh
Subject: Re: [XaraXtreme-dev] Problem in wxWidgets 2.6.3...

Gerry,

I wrote re dragmgr.cpp:
> Firstly, the ScreenToClient() is wrong - the call takes and has
> always taken screen coords not client coords. If this was working,
> it was only by accident (perhaps due to the other bug).
> 
> Secondly, ChildWindowUnderPoint == WindowUnderPoint seems unnecessary.
> The routine has returned that a child window of the target window
> exists which is the deepest window that contains the mouse pointer.
> So it's a drag hit. Why do we care whether or not the child window
> is also the one we found before?

On reflection, I think the second check /is/ actually correct, and is
designed to ensure that there is no window which is NOT a child of
the target window which obscures the target window or its child.

I can only assume the first ScreenToClient() was necessary to work
around the bug we've fixed (in which case removal is correct) or
that the routine never worked properly (ditto). In any case I've
checked it in on this basis and fixed dlgmgr, camview & ccolbar too.

It all seems to work.

We should now not need the wxWidgets patch unless wxWidgets itself
is using the call in a broken way. My only worry is whether it
internally relies on the broken behaviour (I hope not).

Alex