Updating GUI from other threads

General JUCE discussion
1

Hi there, what’s the preferred way of handling UI updates from other threads that doesn’t involve creating MessageManagerLock instances. Is there a general pattern for handling this scenario?

thx

2

It depends on what you’re doing and whether the “other” thread is the audio thread. A simple mechanism for non-audio > main thread communication for components is using postCommandMessage() and handleCommandMessage(). If the other thread is the audio thread then don’t do that (as postCommandMessage() calls new and in any case you might risk flooding the message queue). In this case using a Timer to check a flag (which you can set in your audio thread) works well.

3

thanks for reply - the other thread in this case is a MIDI thread, so I’ll look into postCommandMessage - cheers!

4

at what point is it valid to call postCommandMessage() and have the message delivered? messages that I send early on never get delivered…

5

Try using AsyncUpdater… using a Message can overload the Message queue

Simply triggerAsyncUpdate() and in handleAsyncUpdate() do a repaint().

Rail

3 Likes
6

thx this is much better. Shame it doesn’t have a message to pass, but that’s easy to implement… thx for the suggestion

7

Someone should write a book on this topic :slight_smile:

MessageManager::callAsync() is pretty good - but you need to faff around with weak pointers if there’s any danger of the target object being deleted while the message is in the queue.

I tend to use this a lot:

1 Like
8

ActionBroadcaster / ActionListener does that with a String object, if that carries enough information for you

4 Likes
9

great - thx for the info, that’ll do nicely in this case

10

I think (and you can check me on this) ActionBroadcaster has a lock while ASyncUpdater doesn’t (which may or may nor matter depending on what you’re doing).

Cheers,

Rail