Last updated at 12:24 am UTC on 10 January 2022
If you want to run something that accesses the Morphic UI, even though you are not running from somewhere that the UI is in a sane state, you should normally use addDeferredUIMessage:. Otherwise, you can put Morphic into extremely confused states....
Sean DeNigris I'm still not exactly sure what it does, but I'm collecting info from the web:
Per Ned Konz @ http://wiki.squeak.org/squeak/528:
Deferred UI messages are processed in the middle of the Morphic event loop, just after responding to events, and before doing other step methods and displaying the world. Look for implementors of #addDeferredUIMessage:, look at the one in WorldState, look for senders of #deferredUIMessages, and you'll see WorldState>>runStepMethodsIn: which empties the queue. And it's called from doIf you want to run something that accesses the Morphic UI, even though you are not running from somewhere that the UI is in a sane state, you should normally use addDeferredUIMessage:. Otherwise, you can put Morphic into extremely confused states....
OneCycleNowFor: which is the body of the main Morphic event loop.
Per Wilhelm K Schwab @ http://forum.world.st/Fwd-MouseOverHandler-td1300474.html#a1300474:
provides a clean way to interact with the GUI from background threads
As it is now, it's quite simple to put long-running computations in
background threads; you just don't let the background threads call methods
directly on Morphs. We have addDeferredUIMessage: to queue up action from
the background threads for later execution in the UI thread during the
next window cycle.
It is good style to use
Project current addDeferredUIMessage:
or within a Morph method
self world project addDeferredUIMessage:
self world project addDeferredUIMessage: [self world project world addMorph: (RectangleMorph new )]
When are the deferred UI messages processed?