[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]
Re: [XaraXtreme-dev] ChildWindowFromPoint and other questions
- From: Mark Loumbert <mark@xxxxxxxxxxxxxxx>
- Date: Fri, 14 Apr 2006 14:50:10 +0400
- Subject: Re: [XaraXtreme-dev] ChildWindowFromPoint and other questions
The problem here is much simpler, Alex - currently I'm porting the
Picker's wxOil code that shows help message to the user in the status
bar that should correspond to the child window that is under cursor, so
this is quite straightforward usage. Of course I can use the general
wxFindWindowAtPoint one, but the result won't be the same. In my opinion
it will even be more adequate - if some other window covers the child -
why should I display the help message ? But for the sake of consistency
of a working code, I have first to port exactly the same functionality
and then optimize it trying not to bring the new bugs.
Alex Bligh wrote:
--On 14 April 2006 13:56 +0400 Mark Loumbert <mark@xxxxxxxxxxxxxxx>
My name is Mark, I am currently working on the Colour Editor. So I
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
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
(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,
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
gone into the oil layer but didn't for whatever reason. WITHOUT
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
That's probably not a great idea. You would probably be better using
wxWidgets controls which will look (hopefully) right on all platforms,
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
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
haven't touched before. I think the text is available on-line, but amazon
can certainly do their magic.