wxScrolledWindow mouse events question.
FALKINDER,DAVID (HP-UnitedKingdom,ex2)
Not sure if this is a bug, or just my conceptual misunderstanding .....
So I've a wxScrolledWindow, containing a whole bunch of other controls,
wxStaticText, wxTextCtrl etc.
I was expecting that each of these sub controls would be able to respond to
EVT_ENTER_WINDOW,EVT_LEAVE_WINDOW, or even EVT_MOTION, as the mouse ran over
them. Well ... they don't. Using the catch all "EVT_MOUSE_EVENTS", then I
can see clicks , EVT_LEFT..., EVT_RIGHT.. etc, but no motion / on-over type
events.
I took a look at scrlwing.cpp, but all sorts of wild and wacky stuff is
done, with pretty much most events, and I couldn't follow what was being
done.
As I say, not sure if this is a bug, or just me not getting how things are
supposed to work, so if any guru can shed a little light, it would be
appreciated.
Many thanks in advance,
|\
|/ave
Matt Gregory
Ah, I was just mucking around in there the other day, so I should be quite
familiar with it by now (ha). That class has an autoscrolling feature that
might interfere with those events. But child windows should receive events
before parent windows and derived classes should receive events before base
classes, so there should be no problem, right? Except wxScrolledWindow
uses the event handler chain mechanism to capture its events, so maybe that
changes the event handling semantics. You may have to derive a class from
wxEventHandler and use it to replace the current event handler, instead of
using message maps. But that's just a guess.
HTH,
Matt Gregory
FALKINDER,DAVID (HP-UnitedKingdom,ex2)
Thanks for the quick reply. Not wanting to be picky, but it seems harder
work than it needs to be for wxScrolledWindow to adopt a completely
different approach (i.e. not intuitive), though I'm sure there's a really
good reason for that.... Do you have a feel for if there's opportunity for a
cleanup here, or is this by ideal design.
I noticed in the bowels of that stuff, there's handling of a bunch of the
mouse events, along with paint, draw and a bunch of other stuff. Do you
think an appropriately placed event.Skip, would allow the "normal" process
to work? Or is the issue significantly more complex than that?
As "plan B", deriving (as you suggest) from wxEvtHandler, and overriding,
what's the functionality of the original I need to incorporate (hope this
isn't too dumb a question given I'm not really sure what it's doing)? I may
well be missing the point here ;-)
Many thanks,
|\
|/ave
FALKINDER,DAVID (HP-UnitedKingdom,ex2) wrote:
HTH,
Matt Gregory
---------------------------------------------------------------------
To unsubscribe, e-mail: wx-users-u...@lists.wxwindows.org
For additional commands, e-mail: wx-use...@lists.wxwindows.org
Matt Gregory
> Matt,
>
> Thanks for the quick reply. Not wanting to be picky, but it seems harder
> work than it needs to be for wxScrolledWindow to adopt a completely
> different approach (i.e. not intuitive), though I'm sure there's a really
> good reason for that.... Do you have a feel for if there's opportunity for a
> cleanup here, or is this by ideal design.
I think maybe autoscrolling doesn't belong in wxScrolledWindow, but should
be a separate derived class, or maybe even separate from the library
altogether. It really does make it a very complicated class. I've written
autoscrolling code and it is much, much simpler to write it in the user
program in comparison to putting in such a low-level class. Plus, in
putting it in wxScrolledWindow, you lose the ability to do autoscrolling in
two directions at once, due to the wxScrollEvent class only having one
place to store the distance scrolled.
> I noticed in the bowels of that stuff, there's handling of a bunch of the
> mouse events, along with paint, draw and a bunch of other stuff. Do you
> think an appropriately placed event.Skip, would allow the "normal" process
> to work? Or is the issue significantly more complex than that?
Well, the events are already being skipped in most cases (except for the
mouse wheel, it looks like) But that leads to the following question
(in my mind, anyway): when is the user's event handlers called in relation
to wxScrollWindow's? Are they called before or after? I thought the
user's were called first, then if you skip it, the base class's was called.
But this seems to go the other way around, which kinda makes sense because
you can't really draw until the window has been scrolled.
>
> As "plan B", deriving (as you suggest) from wxEvtHandler, and overriding,
> what's the functionality of the original I need to incorporate (hope this
> isn't too dumb a question given I'm not really sure what it's doing)? I may
> well be missing the point here ;-)
No, it's not a dumb question, because I'm not sure if anyone knows the
answer :-) I think maybe if you call PushEventHandler() on your own
window class, within itself, it will put its event handlers before the
wxScrolledWindow handlers. But that will probably break some stuff,
because some things you'll want to happen before wxScrollWindow, and
some after. But if you derive a different wxEventHandler class, and
make it a friend of your window class, give it an event table, and push
it, then I think you'll be able to selectively put which event handlers
you want to happen before wxScrollWindow's in the wxEventHandler class,
and, leaving the rest in your original window class, which will happen
after wxScrolledWindow's handlers.
ProcessEvent()
|
v
+------------------+ +--------------+ +--------------+
| MyEventHandler | -> | OnMouseEnter | -> | OnMouseLeave | -> etc.
+------------------+ +--------------+ +--------------+
|
v
+------------------+ +------------------+ +------------------+
| wxScrolledWindow | -> | HandleMouseEnter | -> | HandleMouseLeave | -> etc.
+------------------+ +------------------+ +------------------+
|
v
+------------------+ +--------------+ +--------------+
| MyWindow | -> | OnMouseDown | -> | OnWhatever | -> etc.
+------------------+ +--------------+ +--------------+
|
v
?
That's how I conceive of PushEventHandler working. Going from
ProcessEvent to MyEventHandler then going across, then going down, etc.
I'm not really certain if that's how it really works, but I think it is.
Matt Gregory
Vadim Zeitlin
F> So I've a wxScrolledWindow, containing a whole bunch of other controls,
F> wxStaticText, wxTextCtrl etc.
F>
F> I was expecting that each of these sub controls would be able to respond to
F> EVT_ENTER_WINDOW,EVT_LEAVE_WINDOW, or even EVT_MOTION, as the mouse ran over
F> them. Well ... they don't. Using the catch all "EVT_MOUSE_EVENTS", then I
F> can see clicks , EVT_LEFT..., EVT_RIGHT.. etc, but no motion / on-over type
F> events.
Sorry, where do you use it? In wxScrolledWindow or in the child controls?
I do expect the child contracts (although not wxStaticText under Windows)
to get all mouse events, completely independently of autoscrolling in
wxScrolledWindow.
I'm afraid I don't see what _exactly_ the problem is, David.
Thanks,
VZ
FALKINDER,DAVID (HP-UnitedKingdom,ex2)
Sorry for the lack of clarity. I can't see events for the child controls of
the scrolled window. That said to my knowledge I was only checking a
derivative of wxStaticText. You mention "although not wxStaticText under
windows". Is there some restriction here?
Regards,
|\
|/ave
-----Original Message-----
From: Vadim Zeitlin [mailto:zei...@dptmaths.ens-cachan.fr]
Sent: 01 July 2003 23:02
To: wx-u...@lists.wxwindows.org
Subject: Re: wxScrolledWindow mouse events question.
Thanks,
VZ
Vadim Zeitlin
F> Sorry for the lack of clarity. I can't see events for the child controls of
F> the scrolled window. That said to my knowledge I was only checking a
F> derivative of wxStaticText. You mention "although not wxStaticText under
F> windows". Is there some restriction here?
Yes: Windows doesn't generate mouse events for the static controls and
synthesizing moves for them (like we do for the clicks) is too
CPU-intensive, so we don't do it.
Regards,
VZ
FALKINDER,DAVID (HP-UnitedKingdom,ex2)
Thanks for the enlightenment. Gotta love Uncle Bill's consistencies
.....
Now onto plan B ... at least you've saved me a bunch of time messing
around in the dark ... much appreciated.
Many thanks to Matt as well, for the time spent explaining his
experiences..
Regards,
|\
|/ave
-----Original Message-----
From: Vadim Zeitlin [mailto:zei...@dptmaths.ens-cachan.fr]
Regards,
VZ