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
[solved] Preventing cegui control state change
Moderators: CEGUI MVP, CEGUI Team
[solved] Preventing cegui control state change
Last edited by mrzli777 on Tue Jun 03, 2008 08:37, edited 1 time in total.
- CrazyEddie
- CEGUI Project Lead
- Posts: 6760
- Joined: Wed Jan 12, 2005 12:06
- Location: England
- Contact:
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.
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.
- CrazyEddie
- CEGUI Project Lead
- Posts: 6760
- Joined: Wed Jan 12, 2005 12:06
- Location: England
- Contact:
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:
Not important for this particular case, but may be useful in the future
CE.
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.
Who is online
Users browsing this forum: No registered users and 37 guests
