[Solved]Message Listener alternative to MessageManagerLock?

Which is the best Broadcaster/Listener alternative to MessageManagerLock ?

That’s like asking “what’s the best kind of apple to replace my orange?”…

Well,

I’m using MessageManagerLock from a library thread callback to refresh graphics of my app (setVisible, repaint, fadeOutComponent).

i’m to try to replace that by sending message to uncouple UI method from the outside thread.

What is so best to use ? Change broadcast ? Action broadcast ? postcommand message ?

an example of a callback my outside thread uses :

[code]static void callBack(bool isWaited){

const MessageManagerLock mml;
s_UI_address->getCircle()->setVisible(true);
s_UI_address->repaint();

};[/code]

i’d like to change for :

[code]static void callBack(bool isWaited){

const MessageManagerLock mml;
s_UI_address->sendMessage(s_UI_address);

};[/code]

Maybe if you define what you mean by the “best” thing to use, you’ll answer your own question.

By best I mean actually “synchronous” …

My example works perfectly with a ChangeListener e.g., and asychronous sent messages.

Once synchronous, it does not.

Is there a listener allowing to manage priority of its sent messages in the queue ?

Well, here is my way to solve untracking-down troubles with MessageManagerLock.

In the typical configuration :
a component repainted by a third-party thread.

MMLock creates deadlock ? Just use a MessageListener object.

I put a kind of SafeUpdater object in my component.
SafeUpdater inherits from MessageListener

You post message in third-party thread with this SafeUpdater.
And handle them with SafeUpdater as well.
This guaranties more or less message to pass politely in the messageManager queue.
Juce doc says MessageListener posts to be thread-safe.

That works well in my app, bye bye “semaphore wait signal track” de la muerte.

NB : (you cannot make your component inherits from MessageListener, and granularity is not preserved anyway).

Why don’t you use a AsyncUpdater ( http://www.rawmaterialsoftware.com/juce/api/classAsyncUpdater.html ) which works very well and doesn’t need you to rewrite your own wheel ?

Why not… thank you I’ll try your solution.

Fact is I need reactive repaintings. I ask to repaint my UI from my 3rd-party thread, expecting repaint to be mo’o’less immediate.

You can imagine my app is a bit like clips in Ableton Live : you launch numerous clips here and there, repaint should not be too much delayed.

But I make a mistake probably by guessing Async is too slow… If I do, please hit me with giant fist .
:wink: