On Fri, Oct 14, 2011 at 07:26:22AM -0500, Ed Leafe wrote:
> On Oct 14, 2011, at 5:19 AM, Chris G wrote:
> 
> >    self.bindEvent(dabo.dEvents.Hit, self.handleHit) - I can't get my
> >    mind round "but in Dabo we've simplified it so that these actions
> >    all raise the Hit event".  Surely different events need to do
> >    different things don't they?  You can't have every event for a
> >    control (ButtonRightClick, ButtonLeftClick, KeyDown, etc.) calling
> >    the same callback method can you?  Or does one have a switch/case
> >    statement in the callback to see what caused the event?
> 
>       Sorry if that isn't clear. What was meant was that the *primary* event 
> from a user interacting with a control will raise the Hit event. So for a 
> text box, the Hit event is raised when text is entered; for a menu item, the 
> Hit event is raised when the menu is selected; for a button, the Hit event is 
> raised when it is clicked; for a timer, the Hit event is raised when the 
> timer fires.
> 
>       For all other events, the different events are raised, and yes, you 
> need to code for their handlers separately. The advantage of the Hit event is 
> that 90% of the time when you want to handle an interaction with a control, 
> that's the one that you'll need.
> 
OK, understood now, thank you.


> >    Later it says "Event handlers need to be written to accept a single
> >    event object parameter. This event object will have an attribute
> >    named 'EventData' that will contain relevant information about the
> >    event. For example, mouse events will include the x and y coordinate
> >    of the mouse, whether any modifier keys were pressed at the time,
> >    and, if relevant, mouse scroll wheel information. Keyboard events
> >    will contain the value of the key that was pressed, and also any
> >    modifier keys. Menu events will contain the menu prompt of the
> >    selected menu; tree events will contain info about the selected
> >    node; grid events will contain row/column values. " but my event
> >    handler needed two parameters:
> >        def handleKey(self, p2):
> >    Presumably my p2 parameter is the event object parameter, however I
> >    can't find documentation that describes that.
> 
>       Yes, it would be. In much the same way that Python will automatically 
> supply an instance reference as the first parameter when an instance method 
> is called, Dabo will supply an event object parameter to handlers as the 
> second.

OK, but then "... Event handlers need to be written to accept a single
event object parameter." is misleading isn't it, there are two
parameters.  That's part of my question and, secondly, is that second
(dictionary) parameter documented anywhere?

> 
> >    All I can
> >    find is lots of places that say "...which will exist in the
> >    event.EventData dictionary property" so I know that EventData is a
> >    dictionary but I can't really find out anything more about 'event'
> >    nor what keys to use to get data out of EventData.
> 
>       One way to do this is to write something like this as your first pass 
> at an event handler:
> 
> def onSomeEvent(self, evt):
>    print evt.EventData
> 
>       That will show what's available; it will change depending on the 
> control and the event (e.g., it wouldn't make sense for a keypress event to 
> have mouseX/mouseY info).
> 
OK, I can do that, thanks, and it works pretty well.

> >    KeyDown (and other keyboard) events - from what my code does it
> >    seems that there is already a key handler which deals with some keys
> >    (i.e. data entry into a field, all non-control keys simply get
> >    entered as data) and it's only keys that *aren't* handled already
> >    that get passed on to my key handler.  
> 
>       Actually that's not correct. Every keypress will raise an event; for 
> controls such as a textbox, there is a default behavior that is built into 
> the control: add the character at the current insertion point, for example. 
> If you have a handler for the KeyChar event, you can prevent the default 
> behavior by adding the line:
>       evt.stop()
> to the code.
> 
OK, but I don't *really* want to stop the default behaviour.  :-)   I
was just trying to understand how it works.  Does the default handler
for the text box take all the printing characters and put them in the
box and then pass any non-handled characters to any further event
handlers that one implements?  


> > This is OK but is it
> >    documented somewhere?  One *might* want to do something special with
> >    some non-control keys, e.g. switch all to lower case or use some
> >    upper case letters to do something special, how would one do this?
> 
>       Here's one that will prevent the letters x, y and z from being entered 
> into a textbox:
> 
> def myHandler(self, evt):
>       char = evt.EventData.keyChar.lower()
>       if char in ("x", "y", "z"):
>               evt.stop()
> 
Where does this have to go in my AppWizard generated code?  It doesn't
work when I put it in ui/GrdLog.py (the application is called log).  If
I put:-

    self.bindEvent(dabo.dEvents.KeyDown, self.handleKey)

then handleKey gets called for non-printing characters but not for
printing characters.  If I put:-

    self.bindEvent(dabo.dEvents.KeyChar, self.handleKey)

then handleKey *never* gets called for any entered character.

I suspect that I'm calling bindEvent() from the wrong place?


>       If you want to ensure that the characters in a textbox are all upper or 
> lower case, Dabo already has a property named 'ForceCase' that you can set to 
> "lower", "upper", or "title", and as you type, the content of the textbox 
> will be adjusted after each keypress.
> 
OK, it was more an example of the sort of thing I might want to do
rather than an actual requirement.

-- 
Chris Green
_______________________________________________
Post Messages to: Dabo-users@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message: http://leafe.com/archives/byMID/20111014142823.GC5876@chris

Reply via email to