Identifying active buttons/windows

[Scorch]

I have implemented my own taborder widgit, I give it a std::list of CEGUI::Window pointers and it handles tabbing between each one.

I have 2 issues i have not been able to solve.

1: I want to have my tab widget be destroyable. I need to unsubscribe from windows to do this safly. I don't know how to unsubscribe from events.

2: I want to have it more obvious which window is active. Right now the only way to tell which window is active is where the cursor is. This is only really usefull in edit boxes. But buttons and other controls can be active. Is there a way to highlight or outline the current active window?


Thanks,
Scorch.

[Rackle]

Regarding #1, removeAllEvents() or removeEvent() might be what you are looking for.

Regarding #2, you could modify the imagery/looknfeel such that it displays the widgets in a highlighted way; using a different image when it has the focus.

You could try to draw a border/frame around the selected widget. With the previous version you could have dynamically created a StaticText and call its setFrameColours(). Or better yet create it once and then move and size it such that it covers your focused widget. The middle part would have to be transparent, so as to not hide/cover the widget.

A third way is to play with the alpha of the widgets.

Look through http://www.cegui.org.uk/wiki/index.php/Tab_Order for an example. Basically I un-highlight every widget in the tab order and then highlight the one that has the focus. The code also handles the situation where a mouse click is used to give focus to a widget, and properly un-highlight and highlight the widgets.

[CrazyEddie]

Just some clarification on point #1...

The removeEvent() and removeAllEvents() calls affect the events available on the EventSet (from which Window is derived). For code before 0.5.0 RC1, this is unlikely to give the desired results, since if you then attempt to subscribe the events you removed, you will get an exception concerning missing events. In 0.5.0 RC1, this behaviour is changed and actually removing the events would work, though still may not be the ideal solution.

The 'correct' way, is to keep hold of the Event::Connection object returned from the subscribe call, and then use this object to disconnect (unsubscribe) from the event at a later time. Event::Connection is effectively a smart-pointer to the 'real' connection (which is maintained internally), and so Event::Connection objects can be copied and passed around as you like.

Code: Select all

// subscribe the event and keep the returned connection
Event::Connection con =
    myWindow->subscribeEvent("MyEvent", &myHandler);

// Do some funky stuff here!

// Finally, release the event subscription, since we no longer wish to hear about it.
con->disconnect();

HTH

CE.

[Van]

Just some clarification on point #1...

The removeEvent() and removeAllEvents() calls affect the events available on the EventSet (from which Window is derived). For code before 0.5.0 RC1, this is unlikely to give the desired results, since if you then attempt to subscribe the events you removed, you will get an exception concerning missing events. In 0.5.0 RC1, this behaviour is changed and actually removing the events would work, though still may not be the ideal solution.

The 'correct' way, is to keep hold of the Event::Connection object returned from the subscribe call, and then use this object to disconnect (unsubscribe) from the event at a later time. Event::Connection is effectively a smart-pointer to the 'real' connection (which is maintained internally), and so Event::Connection objects can be copied and passed around as you like.

Code: Select all

// subscribe the event and keep the returned connection
Event::Connection con =
    myWindow->subscribeEvent("MyEvent", &myHandler);

// Do some funky stuff here!

// Finally, release the event subscription, since we no longer wish to hear about it.
con->disconnect();

HTH

CE.

CE;

this has been bantted about many times before...I suggest that a method be added to ease this pain....


CEGUI::Window::unSubscribeEvent( "MyEvent", &myHandler);


I opened a ticket in mantis.
http://www.cegui.org.uk/mantis/view.php?id=96

[CrazyEddie]

The current implementation of events do not support such a notion easily. At the moment we are using a signal/slot/connection model supporting multiple connections to a signal by the same slot (admittedly of not much general use!).

If enough people were to ask for the explicit unsubscribe member (please don't go dragging up old forums posts), then we might discuss adding such an ability for the >=0.6.0 event system changes.

CE.

[Scorch]

I took the advice here and I'm using 0.7 alpha on selected boxes. Not exactly what I was looking for but it gets the job done well enough for now untill I can create my own looknfeel.

As for the unregiser, would it be easier to create a method more like:

CEGUI::Window::unSubscribeEvents( &myHandler );
and
CEGUI::Window::unSubscribeEvents( this );

That would at least allow me to destruct objects that are registered cleanly.

For now what I did was create a std::queue of connection objects, and I push onto it each time I register, then in the destructor I pop the queue and disconnect from each one.