[solved] Preventing cegui control state change

For help with general CEGUI usage:
- Questions about the usage of CEGUI and its features, if not explained in the documentation.
- Problems with the CMAKE configuration or problems occuring during the build process/compilation.
- Errors or unexpected behaviour.

Moderators: CEGUI MVP, CEGUI Team

mrzli777
Just popping in
Just popping in
Posts: 19
Joined: Fri Jan 04, 2008 11:22

[solved] Preventing cegui control state change

Postby mrzli777 » Mon Jun 02, 2008 15:57

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
Last edited by mrzli777 on Tue Jun 03, 2008 08:37, edited 1 time in total.

User avatar
CrazyEddie
CEGUI Project Lead
Posts: 6760
Joined: Wed Jan 12, 2005 12:06
Location: England
Contact:

Postby CrazyEddie » Mon Jun 02, 2008 18:41

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.

mrzli777
Just popping in
Just popping in
Posts: 19
Joined: Fri Jan 04, 2008 11:22

Postby mrzli777 » Tue Jun 03, 2008 08:25

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.

User avatar
CrazyEddie
CEGUI Project Lead
Posts: 6760
Joined: Wed Jan 12, 2005 12:06
Location: England
Contact:

Postby CrazyEddie » Tue Jun 03, 2008 08:36

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.


Return to “Help”

Who is online

Users browsing this forum: No registered users and 37 guests