tags:

views:

33

answers:

1

I am developing a GUI that has a canvas and a bunch of controls and crap surrounding it. I want to allow the canvas's event handler a chance to handle events like key presses and such when it doesn't have focus. I want the rest to continue working as normal.

Basically what I want to set up is to tell the frame, "Any event you get that you don't yourself process, forward it on to which ever canvas is currently active." I want the quickest, most painless method of doing so...preferably just a couple lines of code.

The problem comes in things that process key presses to change their state. For example, if you hold ctrl down we stop snapping to grid coordinates but there are conditions in which we are not notified of the press and so can't update the cursor until the user moves their mouse (at which point we check in the event for the key). We only get the press if focus is in the control. We've run into this problem before and just worked around it but now there's these couple of conditions that just can't be worked around without this forwarding mechanism.

Thanks.

=======================================================

Answer is that there really is no simple way to do this. You can't just simply send anything that isn't processed to a child widget because if it doesn't process it then you'll get it again....and then send it down again....etc...stack overflow. I actually got excited when I finally managed to cause this...

You also can't just override ProcessEvent within the application frame. You have to override it in the App derived object that encapsulates the program. The reason for this is that you'll spend a lot of extra time trying to capture events that never reach this point...such as key down (the one I specifically wanted at this time). The wxApp::ProcessEvent function seems to always get called when an event is not processed though.

You can't simply call ProcessEvent on your target (even temporarily forgetting the first paragraph) because it doesn't call the handlers that you've pushed onto it. If the processor for the event was added to the target with PushEventHandler it won't be reached through target->ProcessEvent(event) but instead you need to activate the handlers themselves with target->GetHandler()->ProcessEvent(event).

However, again, you can't even do that because you'll receive anything that wasn't directly processed and send it back...get it back...send it back...

The answer is to write a copy of ProcessEvent in the target's handler(s) that doesn't TryParent in addition to overriding wxApp::ProcessEvent. I ended up just keeping a pointer to the handler that deals with the events I want to forward and then, eventually (behind a bunch of abstraction), calling this->GetEventHashTable().HandleEvent(event,this) with "this" being the handler that needs to be activated. This is the key line within wxEvtHandler::ProcessEvent that actually grabs the function from your table and activates it; it skips the validator, some other crap, and doesn't TryParent.

And that is how I defeated WX and did the impossible.

A: 

You can use the ProcessEvent method.

On the event handlers you want to forward, add

/* Let the canvas process this event too */ 
canvas->ProcessEvent(aEvent);

where "canvas" is a static global pointer to your canvas, and "aEvent" is the event object received by your handler.

This way you can even simulate events! That's what I use for my GUI regression testing system...

Rui Curado
Yeah, working on trying this to see if it works out except I'm checking if my parent processed it first: if(!wxAuiParentFrame::ProcessEvent(....)).... Unfortunately VS2010 went totally ape-shit insane and so I had to scratch everything, recheck out and start over....been a great day so far :P
Noah Roberts
This is NOT working for me and it really should. I'm subclassing wxScrolledWindow to do my work and everything works fine when going through normal channels, but when I call ProcessEvent from the frame it only looks at wxScrolledWindow's handler....it just skips all the handlers I've got pushed onto the handler stack! I thought maybe it was wx's convoluded type system but I overrode it by making my own "process_event" function within the most derived class that calls ProcessEvent. It's really starting to piss me off :p
Noah Roberts
Even stranger...it appears that this doesn't work as documented. ProcessEvent gets called on my frame without reaching my window first. Then, when the focus is in the window I'm trying to target the event gets processed correctly, when the focus is not in that window it's sent to the base class and doesn't hit my handlers.
Noah Roberts
Accepting this as a start to the answer. Complete details will be in question edit.
Noah Roberts