Hi,
i have a controller which listens to change events from 6 list components which can dispatch different change events (like item clicked, item added, …).
It would therefore be interesting for me to know (not only which broadcaster but also) what kind of change event was triggered.
How about to overload the mentioned methods with some sort of (optional) type (could just be a String) argument?
By using that a listener could better decide what the broadcaster actually wants to do.
If that’s not an option how could this be done else?
At the moment the cleanest way to do this is to have different objects to listen to each source. But now that we can finally move to C++11 we’ll be adding new listener functions that use lambdas, which should make this kind of thing much neater!
Are there any examples in the Juce “examples” of a simple way to do what you suggest: to have different objects to listen to each source? It would be awkward to split my listening object into multiple objects. Also when will the better C++11 version be available?
Sort of, but the ActionListener::actionListenerCallback method currently only gets the message string. What i sometimes also need is the ActionBroadcaster reference which initiated the message.
So actually i need a combination of that method and the ChangeListener::changeListenerCallback method.
I’m just about to extend ChangeBroadcaster class with an overloaded method for sendSynchronousChangeMessage which allows sending a type and a message string combined in a struct called BroadcastData.
Well, half of the whole point of ChangeBroadcaster or ActionBroadcaster is that it sends a notification from any thread and you receive it always on the GUI thread.
If you don’t need this “decoupling” functionality, i.e. you need to only communicate synchronously between GUI objects, then the standard Listener approach is cleaner in my opinion:
you define a Listener class which contains the methods corresponding to the events you want to be notified about,
in those objects that may trigger those events (that act as broadcasters), you add a ListenerList <Listener> member which contains all the methods to easily notify the registered listeners
You can find good examples of this pattern in many JUCE components that trigger events
I found this thread while looking for a way to overload ChangeBroadcasters/Listeners. Is there any update on the use of lambdas? It seems like this would be an awesome feature.
