Hello Karijn,
your observation is correct. The primary reason of this behavior is the so-called grab cycle. This concept ensures that a touch interaction (once begun) is always completed even if the touch handler or some of its superior components have been disabled in the meantime. This concept also applies to widgets using touch or key handler. When the user has started to interact with the widget, the interaction is not aborted by changing the 'enabled' state.
In other words: you can consider the 'Enabled' state as 'ready to start user interaction'.
Second cause of this behavior can be related to button animations when the button is released and to delays when signals are delivered to a slot method. Once a signal is sent, disabling the button would not have any effect on the signal being already on the way. The signal will arrive.
If you have a button which may become disabled, I would recommend to test its Enabled state of the button inside the Slot method. For example, in case of a Slot method connected to a concrete button ButtonFoo:
if ( !ButtonFoo.Enabled )
return;
... Handle the event
... or more generic implementation, which evaluates the status of the component sending the signal:
if ( !((Core::Group)sender).Enabled )
return;
... Handle the event
I hope it helps you further.
Best regards
Paul Banach
