Help with: event.Skip()

Marco_Aschwanden · April 6, 2004, 12:47pm

Hi

I have a wxCheckListBox that connects as follows:

EVT_CHECKLISTBOX(self, ID_CLB_CLASSES, self.OnClbClassesChecked)

to this function:

def OnClbClassesChecked(self, event):
   # Alas,
   print "hi"
   import time
   time.sleep(2)
   event.Skip()
   print "bye"

Desired behaviour: The user clicks on a checkbox and nothings seems to happen.
What really happens: The user clicks on a checkbox and it swaps its state (checked --> unchecked)...

I thought, event.Skip() would cancel the action. But here is what happens:

hi [appears, the checkbox is still in its original state, it sleeps for 2 secs]
bye [appears, the checkbox changed its state --> does event.Skip() not work or do I miss something?]

I want to prevent the state change, how can I do that?

Thanks for any hints,
Marco

Adi_Sieker · April 7, 2004, 9:08am

Hi,

from the wxWidgets help.

wxEvent::Skip
void Skip(bool skip = TRUE)

Called by an event handler to tell the event system that the event handler should be skipped, and the next valid handler used instead.

so event.Skip() tell wxWidgets to use the next event handler because your event handler currently doesn't want todo anything.

just not calling event.Skip() from your event handler
should do the trick.

Regards
Adi

Marco Aschwanden wrote:

···

Hi

I have a wxCheckListBox that connects as follows:

EVT_CHECKLISTBOX(self, ID_CLB_CLASSES, self.OnClbClassesChecked)

to this function:

def OnClbClassesChecked(self, event):
  # Alas,
  print "hi"
  import time
  time.sleep(2)
  event.Skip()
  print "bye"

Desired behaviour: The user clicks on a checkbox and nothings seems to happen.
What really happens: The user clicks on a checkbox and it swaps its state (checked --> unchecked)...

I thought, event.Skip() would cancel the action. But here is what happens:

hi [appears, the checkbox is still in its original state, it sleeps for 2 secs]
bye [appears, the checkbox changed its state --> does event.Skip() not work or do I miss something?]

I want to prevent the state change, how can I do that?

Thanks for any hints,
Marco

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

Marco_Aschwanden · April 7, 2004, 9:20am

I commented the line 'event.Skip()' out
And no, it doesn't do the trick. The checkbox will change its state (checked <--> unchecked).

It seems as if the gui-event ((un-)paint the checkmark) cannot be surpressed and it happens after the handler has done its job...

I tried as well: event.Skip(True) / event.Skip(1) / event.Skip(False) / event.Skip(0)

thanks for your hint anyway,

Marco

···

On Wed, 07 Apr 2004 11:08:04 +0200, Adi Sieker <ml@sieker.info> wrote:

Hi,

from the wxWidgets help.

wxEvent::Skip
void Skip(bool skip = TRUE)

Called by an event handler to tell the event system that the event handler should be skipped, and the next valid handler used instead.

so event.Skip() tell wxWidgets to use the next event handler because your event handler currently doesn't want todo anything.

just not calling event.Skip() from your event handler
should do the trick.

Adi_Sieker · April 7, 2004, 9:35am

Marco Aschwanden wrote:

Hi,

from the wxWidgets help.

wxEvent::Skip
void Skip(bool skip = TRUE)

Called by an event handler to tell the event system that the event handler should be skipped, and the next valid handler used instead.

so event.Skip() tell wxWidgets to use the next event handler because your event handler currently doesn't want todo anything.

just not calling event.Skip() from your event handler
should do the trick.

I commented the line 'event.Skip()' out
And no, it doesn't do the trick. The checkbox will change its state (checked <--> unchecked).

It seems as if the gui-event ((un-)paint the checkmark) cannot be surpressed and it happens after the handler has done its job...

IIRC, Robin mentioned that a few event are handled after the plattform specific events have happend so canceling them isn't possible.
Maybe this is one of those situations.

I tried as well: event.Skip(True) / event.Skip(1) / event.Skip(False) / event.Skip(0)

thanks for your hint anyway,

With a TextCtrl it works. :))

this should also do the trick with a wxCheckListBox

self.clb.Check(event.GetInt(), False)

I tried it.

Regards
Adi

···

On Wed, 07 Apr 2004 11:08:04 +0200, Adi Sieker <ml@sieker.info> wrote:

Marco_Aschwanden · April 7, 2004, 10:04am

Not quite 8o) But you were almost there:

# has already the new state!!!! So we have to switch it!
if self.clb.IsChecked(event.GetInt()):
self.clb.Check(event.GetInt(), False)
else:
self.clb.Check(event.GetInt(), True)

Or less explicit in one line:

# has already the new state!!!! So we have to switch it!
self.clb.Check(event.GetInt(), (not self.clb.IsChecked(event.GetInt())))

But this behaviour is not quite right (at least it seems to me not quite right). clb is already changed when it enters the event handler. This should not be. Should it? That is why the event.Skip() seems not to work, because the clb is already changed. Is this a bug or a feature?

Thanks for finding the answer/workaround. I would be interested in: whether this is a "bug" or intended behaviour.

Thanx,
Marco

···

On Wed, 07 Apr 2004 11:35:47 +0200, Adi Sieker <ml@sieker.info> wrote:

this should also do the trick with a wxCheckListBox

self.clb.Check(event.GetInt(), False)

I tried it.

Adi_Sieker · April 7, 2004, 10:10am

Marco Aschwanden wrote:

this should also do the trick with a wxCheckListBox

self.clb.Check(event.GetInt(), False)

I tried it.

Not quite 8o) But you were almost there:

Oh, my missunderstanding of "nothing seems to happen".
If the checkbox is checked it wouldn't work of course.

[snip]

# has already the new state!!!! So we have to switch it!
self.clb.Check(event.GetInt(), (not self.clb.IsChecked(event.GetInt())))

But this behaviour is not quite right (at least it seems to me not quite right). clb is already changed when it enters the event handler. This should not be. Should it? That is why the event.Skip() seems not to work, because the clb is already changed. Is this a bug or a feature?

Thanks for finding the answer/workaround. I would be interested in: whether this is a "bug" or intended behaviour.

I think Robin is probably the best person to answer the question about bug or no bug.

Regards
Adi

···

On Wed, 07 Apr 2004 11:35:47 +0200, Adi Sieker <ml@sieker.info> wrote:

K_Owens · April 7, 2004, 11:09am

Marco-

I'd imagine that it's intentional. Perhaps you'd get more mileage out of
enabling/disabling the checkbox or even sinking the mouse down event and
then skipping it if necessary. The latter was the approach I used to combine
a checkbox and a popup menu and it worked out very well.

Regards

KJO

···

-----Original Message-----
From: news [mailto:news@sea.gmane.org] On Behalf Of Marco Aschwanden
Sent: Wednesday, April 07, 2004 6:04 AM
To: wxpython-users@lists.wxwindows.org
Subject: [wxPython-users] Re: Re: Help with: event.Skip()

On Wed, 07 Apr 2004 11:35:47 +0200, Adi Sieker <ml@sieker.info> wrote:

this should also do the trick with a wxCheckListBox

self.clb.Check(event.GetInt(), False)

I tried it.

Not quite 8o) But you were almost there:

# has already the new state!!!! So we have to switch it!
if self.clb.IsChecked(event.GetInt()):
self.clb.Check(event.GetInt(), False)
else:
self.clb.Check(event.GetInt(), True)

Or less explicit in one line:

# has already the new state!!!! So we have to switch it!
self.clb.Check(event.GetInt(), (not self.clb.IsChecked(event.GetInt())))

But this behaviour is not quite right (at least it seems to me not quite
right). clb is already changed when it enters the event handler. This should
not be. Should it? That is why the event.Skip() seems not to work, because
the clb is already changed. Is this a bug or a feature?

Thanks for finding the answer/workaround. I would be interested in:
whether this is a "bug" or intended behaviour.

Thanx,
Marco

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

Grimmtooth · April 7, 2004, 12:44pm

Adi Sieker wrote:

from the wxWidgets help.

wxEvent::Skip
void Skip(bool skip = TRUE)

Called by an event handler to tell the event system that the event handler should be skipped, and the next valid handler used instead.

so event.Skip() tell wxWidgets to use the next event handler because your event handler currently doesn't want todo anything.

That is indeed what the docs say, but I think they're wrong based on observation and some comments from Robin over in -dev a while back.

.Skip() does *not* block the event from being acted upon. After all, you are already in the event handler at that point. The event has *already* happened. In fact, you can make Skip() the very first method called in your event handler and still go on to process it.

However, if you do *not* call Skip(), it will *not* propogate up to the next event handler. This is useful in some cases but not in others.

Some events support a .Veto() method, but not a CommandEvent, which is what you get from a wx.CheckBox. If Veto() were available, that would be the method to use.

As far as I can tell, there is no means to stop a CommandEvent from happening once you hit its event handler.

The best way to avoid a checkbox from being togged is to use .Enable(False).

Marco_Aschwanden · April 7, 2004, 1:02pm

I was thinking about it at lunch. And yeah, when a text event EVT_TEXT() happens, the char is already in the text control and the thing that happens in the checkbox is the same (the checkmark is already set or unset)... it is consistent in its behaviour. But then, what is the event.Skip() good for? It does nothing... or does it?

To me it looks as follows:
1. The default event handler is called:
   - in case of EVT_TEXT the char is added/deleted whatsoever
   - in case of EVT_CHECKLISTBOX the checkbox is swapped (checked <--> unchecked)
2. The "user" defined handler is called:
   - in case of EVT_TEXT you may have to become active to restore its state
   - in case of EVT_CHECKLISTBOX you have to become active to reverse the checkmark
3. The GUI-repaint takes place

In this case the Python-Event-handler is a POST-Event-handler. But what is the event.Skip() method good for? It does not prevent/revert step 1. Maybe event.Skip() was not thought for POST-Event-handler?

I don't know. I think, it is my misconception of the (post) event handling model (I was expecting a PRE-Event-handling) and I accept that my thinking was wrong. But I still cannot see the use of event.Skip(). Can anyone bring light into this matter?

Cheers,
Marco

···

On Wed, 7 Apr 2004 07:09:28 -0400, K Owens <kowenswp@hotmail.com> wrote:

I'd imagine that it's intentional. Perhaps you'd get more mileage out of
enabling/disabling the checkbox or even sinking the mouse down event and
then skipping it if necessary. The latter was the approach I used to combine
a checkbox and a popup menu and it worked out very well.

Regards

KJO

K_Owens · April 7, 2004, 1:16pm

Marco-

For example:

A KeyDown event precedes a Character event. If you have event handlers for
both then you'll need to call event.Skip() in the EVT_KEY_DOWN handler so
that the handler for EVT_CHAR is actually called. Think of not calling it as
a way to prevent the native control from processing the event. Similarly
with MouseDown and MouseClick events. I suppose that the Skip() really means
'skip to the next event handler in the chain'.

Regards

Kieran

···

-----Original Message-----
From: news [mailto:news@sea.gmane.org] On Behalf Of Marco Aschwanden
Sent: Wednesday, April 07, 2004 9:03 AM
To: wxpython-users@lists.wxwindows.org
Subject: [wxPython-users] Re: Re: Re: Help with: event.Skip()

On Wed, 7 Apr 2004 07:09:28 -0400, K Owens <kowenswp@hotmail.com> wrote:

I'd imagine that it's intentional. Perhaps you'd get more mileage out
of enabling/disabling the checkbox or even sinking the mouse down
event and then skipping it if necessary. The latter was the approach I
used to combine a checkbox and a popup menu and it worked out very
well.

Regards

KJO

I was thinking about it at lunch. And yeah, when a text event EVT_TEXT()
happens, the char is already in the text control and the thing that happens
in the checkbox is the same (the checkmark is already set or unset)... it is
consistent in its behaviour. But then, what is the
event.Skip() good for? It does nothing... or does it?

To me it looks as follows:
1. The default event handler is called:
   - in case of EVT_TEXT the char is added/deleted whatsoever
   - in case of EVT_CHECKLISTBOX the checkbox is swapped (checked <-->
unchecked)
2. The "user" defined handler is called:
   - in case of EVT_TEXT you may have to become active to restore its state
   - in case of EVT_CHECKLISTBOX you have to become active to reverse the
checkmark 3. The GUI-repaint takes place

In this case the Python-Event-handler is a POST-Event-handler. But what is
the event.Skip() method good for? It does not prevent/revert step 1. Maybe
event.Skip() was not thought for POST-Event-handler?

I don't know. I think, it is my misconception of the (post) event handling
model (I was expecting a PRE-Event-handling) and I accept that my thinking
was wrong. But I still cannot see the use of event.Skip(). Can anyone bring
light into this matter?

Cheers,
Marco

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

Robin · April 9, 2004, 12:00am

Marco Aschwanden wrote:

I'd imagine that it's intentional. Perhaps you'd get more mileage out of
enabling/disabling the checkbox or even sinking the mouse down event and
then skipping it if necessary. The latter was the approach I used to combine
a checkbox and a popup menu and it worked out very well.

Regards

KJO

I was thinking about it at lunch. And yeah, when a text event EVT_TEXT() happens, the char is already in the text control and the thing that happens in the checkbox is the same (the checkmark is already set or unset)... it is consistent in its behaviour. But then, what is the event.Skip() good for? It does nothing... or does it?

It mearly sets a flag that is checked when the event handler returns.
If the flag is set then the system continues looking for matching event
handlers (in parent classes, and if it is a command event then in parent
windows also.) If there is no other matching event handler then nothing
else happens and the system is told that the event was not handled. If
Skip is not called, then ProcessEvent() stops looking for another
handler and just returns to the system telling it that the event was
handled.

···

On Wed, 7 Apr 2004 07:09:28 -0400, K Owens <kowenswp@hotmail.com> wrote:

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