[Q] making use of key events

Rolf_Marvin_Boe_Lind · February 8, 2003, 11:05pm

I would like to be able to use key modifiers in a program.

I have a wxFrame that contains

EVT_KEY_DOWN (self.Toolbar,1,self.CharEvt)

and a

def CharEvt(self,event): ...

self.CharEvent is indeed triggered by the shift key. self.Toolbar is a
reference to a wxPanel instance controlled by sizers. the wxPanel has
a lot of buttons associated to it.

I can't think of a way to make the buttons understand that shift is
pressed.

this is CharEvt:

    def CharEvt (self, event):
        if event.ShiftDown():
            self.Toolbar.ShiftIsDown = true
        else:
            self.Toolbar.ShiftIsDown = false
        event.Skip()

and sure enough, ShiftIsDown is being set but not reliably, so the
wxButtons can't tell if the shift key is pressed by looking at
self.ShiftIsDown.

any and all help appreciated.

···

--
Rolf Lindgren http://www.roffe.com/
roffe@tag.uio.no

Rolf_Marvin_Boe_Lind · February 9, 2003, 12:55pm

[Rolf Marvin Bøe Lindgren]

I would like to be able to use key modifiers in a program.

this came out a bit messy. let's have another go.

I would like to detect whether shift is down when the user clicks on a
button. I've created a wxPanel which has all the buttons attached. an
EVT_KEY construct shows or hides the toolbar depending on whether the
shift key is pressed or not.

this works, sort of. shift is pressed, the panel with the buttons is
hidden. shift is released, it pops back up again. intil one of the
buttons is pressed - then the panel stays on independent of whether
shift is pressed or not.

does this sound familiar? here's the relevant code:

self.Toolbar = wxToolbar (self, -1)

EVT_KEY_DOWN (self.Toolbar,self.CharEvt)
EVT_KEY_UP (self.Toolbar,self.CharEvt)

    def CharEvt (self, event):
        if event.ShiftDown():
            self.Toolbar.Show (false)
            event.Skip()
        else:

any and all help appreciated.

···

--
Rolf Lindgren http://www.roffe.com/
roffe@tag.uio.no

Mike_C_Fletcher2 · February 9, 2003, 5:39pm

Check that you're binding the key events for all sub-controls on your toolbar. If the focus is on a sub-control (e.g. a real button control) then the parent window won't get the key events (they aren't AFAIK command-type events). In other words, sounds like the child window is eating your key-event for the shift-up.

Good luck,
Mike

Rolf Marvin Bøe Lindgren wrote:

···

[Rolf Marvin Bøe Lindgren]

I would like to be able to use key modifiers in a program.

this came out a bit messy. let's have another go.

I would like to detect whether shift is down when the user clicks on a
button. I've created a wxPanel which has all the buttons attached. an
EVT_KEY construct shows or hides the toolbar depending on whether the
shift key is pressed or not.

this works, sort of. shift is pressed, the panel with the buttons is
hidden. shift is released, it pops back up again. intil one of the
buttons is pressed - then the panel stays on independent of whether
shift is pressed or not.

does this sound familiar? here's the relevant code:

       self.Toolbar = wxToolbar (self, -1)

       EVT_KEY_DOWN (self.Toolbar,self.CharEvt)
       EVT_KEY_UP (self.Toolbar,self.CharEvt)

   def CharEvt (self, event):
       if event.ShiftDown():
           self.Toolbar.Show (false)
           event.Skip()
       else:

any and all help appreciated.

--
_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/

Rolf_Marvin_Boe_Lind · February 9, 2003, 10:12pm

[Mike C. Fletcher]

Check that you're binding the key events for all sub-controls on your
toolbar. If the focus is on a sub-control (e.g. a real button
control) then the parent window won't get the key events (they aren't
AFAIK command-type events). In other words, sounds like the child
window is eating your key-event for the shift-up.

I've just found out that the key bindings get caught again if I click
on the main window after I clicked on the toolbar window. the toolbar
window receives button events, but refuse to receive key events. and
that is mighty confusing, for behold:

from class Frame1 (wxFrame):

self.Window = SymLogWindow(self, -1)
self.Toolbar = Toolbar (self, -1)

self.Toolbar.Show(true)

EVT_BUTTON(self.Toolbar,ID_BUTTON0,self.OnMoveLeft)
EVT_BUTTON(self.Toolbar,ID_BUTTON1,self.OnMoveRight)

...

EVT_KEY_DOWN (self.Toolbar,self.KeyDown)
EVT_KEY_UP (self.Toolbar,self.KeyUp)

...

        self.sizer.Add(self.Toolbar,1,wxEXPAND|wxALIGN_LEFT)
        self.sizer.Add(self.Window,0,wxBU_EXACTFIT)

        self.SetSizer(self.sizer)
        self.SetAutoLayout(1)
        self.sizer.Fit(self)

so the key events are bound to the toolbar, but the toolbar refuses to
accept key events from itself, only from other windows!

how can I ensure that parents and children alike don't eat the key
events?

···

--
Rolf Lindgren http://www.roffe.com/
roffe@tag.uio.no

Rolf_Marvin_Boe_Lind · February 10, 2003, 8:26pm

[Mike C. Fletcher]

Check that you're binding the key events for all sub-controls on your
toolbar. If the focus is on a sub-control (e.g. a real button
control) then the parent window won't get the key events (they aren't
AFAIK command-type events). In other words, sounds like the child
window is eating your key-event for the shift-up.

OK, I found out that I need to include every gosh dang button control
to an EVT_KEY_UP and EVT_KEY_DOWN. that's gotta be a lot of
EVT_KEY_UPs and EVT_KEY_DOWNs. but I can live with that. I don't have
to type much. I use Emacs.

···

--
Rolf Lindgren http://www.roffe.com/
roffe@tag.uio.no

Chris_Barker1 · February 10, 2003, 8:20pm

Hi all,

I made a little demo of some things you can do with toolbars a while
ago, and never got around to putting it in the Wiki. Matt's question
reminded me, so I've just put it up:

http://wiki.wxpython.org:80/index.cgi/WorkingWithToolBars

Please check it out and comment and/or add to it.

By the way, I'm getting a wierd error on the Wiki page in the code in
the middle of a triple quoted string:

ERROR: EOF in multi-line string

Given that the rest of the code is there, and the same code works fine
and colorizes fine in Emacs, I have no idea what the problem is.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

Mark_Melvin · February 10, 2003, 9:09pm

Cool little demo, Chris.

The problem I think is the extraneous triple quote at the very top of the code, just before the wx import statement.

Mark.

cbarker@dspfactory.com wrote:

···

Hi all,

I made a little demo of some things you can do with toolbars a while
ago, and never got around to putting it in the Wiki. Matt's question
reminded me, so I've just put it up:

http://wiki.wxpython.org:80/index.cgi/WorkingWithToolBars

Please check it out and comment and/or add to it.

By the way, I'm getting a wierd error on the Wiki page in the code in
the middle of a triple quoted string:

ERROR: EOF in multi-line string

Given that the rest of the code is there, and the same code works fine
and colorizes fine in Emacs, I have no idea what the problem is.

-Chris

--

________________________________________
Mark Melvin, P.Eng.
Member of Technical Staff - Software Tools
Dspfactory Ltd.
611 Kumpf Drive, Unit 200
Waterloo, Ontario, Canada N2V 1K8

Tel: +1 519 884 9696 Ext. 2245
Fax: +1 519 884 0228
http://www.dspfactory.com
________________________________________

Chris_Barker1 · February 10, 2003, 8:52pm

Mark Melvin wrote:

The problem I think is the extraneous triple quote at the very top of
the code, just before the wx import statement.

That was it. Thanks for finding it. Thanks also to Chris Olds who also
pointed it out.

It turns out that making a Wiki page is fun and satisfying... I'd love
to see more!

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

Robin · February 10, 2003, 10:02pm

Rolf Marvin B?e Lindgren wrote:

and sure enough, ShiftIsDown is being set but not reliably, so the
wxButtons can't tell if the shift key is pressed by looking at
self.ShiftIsDown.

KEY/CHAR events are sent to the window that has the keyboard focus. If the buttons or toolbar do not have the focus, then you won't get the event there. Unfortunatly we don't currently have a crossplatform way to get the status of the modifier keys at any point in time. The only solution is to bind the event to every window/control in your app that could possibly get the focus...

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

Robin · February 10, 2003, 10:02pm

Rolf Marvin B?e Lindgren wrote:

[Mike C. Fletcher]

> Check that you're binding the key events for all sub-controls on your
> toolbar. If the focus is on a sub-control (e.g. a real button
> control) then the parent window won't get the key events (they aren't
> AFAIK command-type events). In other words, sounds like the child
> window is eating your key-event for the shift-up.

OK, I found out that I need to include every gosh dang button control
to an EVT_KEY_UP and EVT_KEY_DOWN. that's gotta be a lot of
EVT_KEY_UPs and EVT_KEY_DOWNs. but I can live with that. I don't have
to type much. I use Emacs.

Another way to do it is to put the handler in a class derived from wxEvtHandler, and then push a new instance of this class onto all the widgets with button.PushEventHandler(...)

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!