Page 1 of 1

[solved] Preventing cegui control state change

Posted: Mon Jun 02, 2008 15:57
by mrzli777
Hello people.

Is there a way to prevent a cegui control to change it's state in event handler.

Let me clarify a bit:
I have a checkbox for example, and I want to prevent the user from checking/unchecking it if a certain condition is fulfilled (whatever, some variable is > 10), and I check for that condition in the handler for EventCheckStateChanged for example.
I tried returning false (thought that might do the trick), and the checkbox was still changed. (const EventArgs &) e and it's e.handled is read-only.
Can I do something in that (or any other) event handler that will prevent the checkbox from changing it's state on mouse click, other than disabling the control?

Thx

Posted: Mon Jun 02, 2008 18:41
by CrazyEddie
Hi,

In a general sense, subverting the 'normal' behavior of widgets is not really provided for; I do understand that in some cases this can be desirable though.

For the example you gave, this can be achieved by subscribing to CEGUI::Window::EventMouseButtonDown and if you want to stop the 'usual' behavior, just call Window::deactivate to deactivate the window (that is deactivate, not disable) - this will prevent the mouse capture and thus prevent the widget from changing state.

Note that when you subscribe to an event such as EventCheckStateChanged, the change has already occurred (so I guess another solution would be to use the opportunity to reverse that change - though beware of recursive event calls).

CE.

Posted: Tue Jun 03, 2008 08:25
by mrzli777
Nice.

deactivate() works as expected. I tried reversing the change before, but it caused recursive calls and stack overflow. But it doesn't matter since deactivate() works nice.

Thank you CE.

Posted: Tue Jun 03, 2008 08:36
by CrazyEddie
Glad it works :)

For reference, if anybody ever needs to alter a widget state in the handler for the same state being modified; that is, if you are likely to experience recursive calls, you can alleviate the issue by surrounding the code that would trigger the event with mute / unmute calls on the EventSet:

Code: Select all

// imagine this code is in an event handler of some kind
...
// mute events
myWindow->setMutedState( true );

// TODO: Code that would fire the handler that this code is in!

// mute events
myWindow->setMutedState( false );

...


Not important for this particular case, but may be useful in the future :)

CE.