Page 1 of 1

About events.

Posted: Wed Dec 01, 2004 08:49
by Spoke
Hi!

While reading the code, I see that the unsuscribe method is private, so I would like to know which is the right way to unsuscribe an event without destroying the sender or receiver.

Thanks! :wink:

About events.

Posted: Wed Dec 01, 2004 11:25
by CrazyEddie
When you subscribe to an event you get returned a CEGUI::Event::Connection object. This can be used to disconnect / unsubscribe by calling the disconnect() method. There's also a CEGUI::Event::ScopedConnection class that will auto-disconnect when the ScopedConnection object goes out of scope.

HTH

CE.

About events.

Posted: Wed Dec 01, 2004 11:48
by Spoke
Thanks for the quick reply! ;)

This is the scenario:

I want to have a handle function that will subscribe to all the event of one type of gui element. Let´s say it is a PushButton for simplicity and the EventClicked event.

So if I suscribe all the instances of pushbutton with this unique function I need to keep a copy of each connection object in order to unsuscribe them?

Is there a way to avoid having that reference?, like requesting it or something?

Thanks!

About events.

Posted: Wed Dec 01, 2004 13:55
by CrazyEddie
Yeah, you pretty much need to track those Connection objects :? The internals of it are that each subscription to an event creates a new internal 'subscriber' object; the only external way to control that is via the returned Connection.

Since you're obviously after something a little more advanced, you might consider sub-classing the types you're targetting and setting up something custom built via the Windows on<event> handlers (which you could code in such a way to enable quick and easy connections right across all instances of the type). If you register a factory for your subclasses and alias them to the 'normal' type (for example Taharez/Button), then whenever a widget of that type is requested, they'd actually get your sub-class.

Not sure if that's explained very well, but I hope so ;)

CE.

About events.

Posted: Wed Dec 01, 2004 21:27
by Spoke
ummm, interesting idea, I will think over it a little.

About events.

Posted: Thu Dec 02, 2004 20:25
by Spoke
Ok, but why is the event unsubscribe private?

Should not be public and have a unsubscribeEvent call?

That will prevent the storing of the connection object, no?

About events.

Posted: Fri Dec 03, 2004 09:52
by CrazyEddie
The unsubscribe method is an implementation method, I'm not entirely sure if it works the way you want it to :)

Have you tried making it public and running a few tests to see if it works okay? If it does, let me know, and I'll run a few tests of my own and will consider promoting the method into the public interface.

CE.

About events.

Posted: Sun Dec 05, 2004 09:00
by Spoke
Nope, I was asking in order to get the designer view before getting my hand dirty. :wink:

I will give it a a try and tell you how it goes.