Re: [XaraXtreme-dev] ChildWindowFromPoint and other questions

[Alex Bligh <alex@xxxxxxxxxxx>]

Mark,

--On 14 April 2006 13:56 +0400 Mark Loumbert <mark@xxxxxxxxxxxxxxx> wrote:

> My name is Mark, I am currently working on the Colour Editor. So I have a
> few questions. Does anyone already implemented the Win32's
> ChildWindowFromPoint functionality somewhere in wxOil ?

Not that I know of.

> It is used to
> find the immediate child window from the given point in client coordinate
> system of a parent.  I was not able to find the analog in wxWidgets,
> maybe you can point it out ? It is not quite the same as
> wxFindWindowAtPoint - this finds the deepest window, not neccessary the
> child of a particular parent from a point. If no one does that then I
> consider implementing it myself - it is quite straightforward. Then what
> is the better place to put it ?

Let's assume for the moment you were just going to call wxFindWindowAtPoint
(which might be adequate, who knows). In this case, you should implement
the call in DialogManager (wxOil/dlgmgr.cpp), using the same sort
of parameters as the other callers, and being careful to use the
same sort of types. You should then introduce the relevant "short-cut"
call into Kernel/dialogop.cpp as well (this simply saves dialogs
having to get the address of the dialog manager instance) - this
is normally a single line.

It sounds like you might need to do some depth-first search of the
child windows of a particular window in order to tell which covers
the point in question (I think that's the distinction you are trying
to make - i.e. if there is a window which is neither the window
in question nor a child thereof which covers the point in question,
you want to either ignore it or return some form of error I guess).
If so, that code can equally well live in wxOil/dlgmgr.cpp. If your
code has much wider application you might want to write it as if
contributing it to wx and stick it in the wxXtra directory. In this
instance it sounds sufficiently small that just putting it in dlgmgr.cpp
will do fine.

Just as a general point, there are times where I've got to thinking "this
would be easier to rewrite the way wxWidgets intends it to be done, rather
than port call by call". This is certainly where I got to with the bars
stuff. It sounds like the colour editor has lots of stuff that should have
gone into the oil layer but didn't for whatever reason. WITHOUT READING THE
CODE I can't immediately think /why/ it needs ChildWindowFromPoint etc. -
it sounds like what it's trying to do is draw controls etc. in the kernel.
That's probably not a great idea. You would probably be better using native
wxWidgets controls which will look (hopefully) right on all platforms, or,
if that doesn't work, just writing the control itself in the Oil layer,
and loading it through the XRC mechanism (and adapting the dialogmanger
interface). I had (well, am having) a similar problem to this with
galleries as per my message yesterday: the kernel currently renders
it's own scroll-bar (pixel by pixel, rectangle by rectangle) - this
is not a very kernel thing to do, and will look completely wrong
on the Mac (where a windows scrollbar will appear). So I am instead
going to use a wxControl derivative (wxScrollbar) and fix the oil
layer up to handle it. Remember the original idea of kernel dialogs
was that they just sent messages to the kernel and there was meant
to be no idea of "in dialog" mouse positions etc.

> Another question - where can I find the latest and the most complete
> documentation on wxWidgets ? wxWidgets.org docs seem to be a little
> shallow.

I use either the 2.6.3 documentation from wxWidgets.org (the alphabetical
class reference seems most useful), or just go and look at the source. I
also have Julian Smart's and Stefan Csomor's wxWidgets book, which adds
some useful background which is good if you are embarking upon an area you
haven't touched before. I think the text is available on-line, but amazon
can certainly do their magic.

Alex