Title: Explanation of form's internal event model Status: Current Created: 2002-07-17 This is an abridged/edited transcript from #gnuenterprise. It needs to be restructured into an actual technote. ----------------------------------------- StyXman: issues with events? jamest: uh, yes, I'm still lost I see that only a gfinstance can dispatch events what are you trying to do? jamest: I want to put behaviour on {gf,ui}scrollbar so, I want to make the uisb send a n event that the gfsb is listening to have you happened to look at UIButton in the wx driver? it maps a wx event to a GF event but it uses self._eventHandler instead of dispatchEvent. I was told to use the latter... (ok, not told, just suggested...) huh but my first implementation was to use _eventHandler... that looks wrong and what does event.eventHandler has? I mean, @ _createWidget time... is not clear to me that a uisb function is called. add the _setDefaultEventHandlers(newWidget, event.eventHandler, event.initialize) seen in the button creation to the scrollbar creation wait ok, the confusion comes from some of this being wxpython "events" and some of this being gnue "events" jamest: did you see my question about event.eventHandler? in the button code you've got EVT_BUTTON() which sets the function to call when the user generates a wx button click I realized that... then the next line containing the (event.eventHandler) is pushing the mouse and UI event handlers onto the wx event processing stack we used to have every widget contain the duplicate code for this IIRC the reason we're passing that event.eventHandler in is that those classes (mouse and UI event) dont register as event aware jamest: so, I set up a uihandler, def'ing a uisb's method and calling EVT_WE and also set a handler (event.eventHandler; btw, I hate that 'event' name) with _setDefault... but what value does event.eventHandler have? again, is not clear to me that it will be a uisb's method I mean, how do I tell that ceratin gfsb's method should be called? that's mapped in the GFInstance all events are processed thru there as sort of a clearing house aha, so if I register my uisb to listen to certain event, gfinstance will take care of that. so you'd setup a funciton in there that did the approprate calls to the lower level gfobjects it also does the focusing you'll notice a lot of events are named requestFOO because the UI is a slave to the GF tree it can make requests from the GF tree but it's not allowed to update it's own contents w/o getting events back from the GF tree it's not allowed to change focus with events from the GF tree it's a complete mindless slave to the GF tree humbly requesting that something be done then waiting until it's told to do something er, wait, that's not it "it's a complete mindless slave to..." it was so that we had a single code base that handled things like max length, input masks, uppercase conversion, etc, etc i didn't want to see each UI implement things in their own fashion would you say that I should 'build' a new event, like requestSCROLL? jamest: and is not registerEventListeners too much hardcoded? no, it is not. I misinterpreted... oh yes, new events would probably be required and hack (i'll say 'hardcode') gfinstance event name are hardcoded in gfinstance yes I mean, I would spect that the ui objet to register new events. if we allow UI plug-ins in the future we'll need some way to register them but everything so far is pretty much std behaviour so I'm not too worried about the hard coding -----------------------------------------