| m | m := Morph new. m openInWorld. m color: Color red. [1 to: 300 do: [:x | WorldState addDeferredUIMessage: [m extent: x@300]. (Delay forMilliseconds: 10) wait. ]. WorldState addDeferredUIMessage: [m delete] ] fork. would be the proper way to do things to avoid unpleasant side effects Though, for this example, you can get away with the following: | m | m := Morph new. m openInWorld. m color: Color red. 1 to: 300 do: [:x | m extent: x@300. World displayWorldSafely. (Delay forMilliseconds: 10) wait. ]. m delete Regards, Gary ----- Original Message ----- From: "Sean P. DeNigris" <sean@clipperadams.com> To: <pharo-project@lists.gforge.inria.fr> Sent: Thursday, June 21, 2012 4:51 PM Subject: Re: [Pharo-project] Worskpace question
Hilaire Fernandes wrote
To get the animation, you have to enclose the loop in a forked process, but it is inelegant: ... [1 to: 300 do: [:x | m extent: x@300. (Delay forMilliseconds: 10) wait. ]. m delete] fork.
Hilaire, why don't you like this? It seems very straightforward. You're doing a long-running operation and you want another thread to run concurrently. Fork seems like the natural choice.
The only other issue is #addDeferredUIMessage: which Guille mentioned. I'm unclear exactly what kinds of Morphic interaction require it and haven't been able to get a clear answer. Your sample block doesn't seem to hurt morphic, but if you experience weirdness (like red X's), that's probably where to look.
Sean
-- View this message in context: http://forum.world.st/Worskpace-question-tp4635656p4635943.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.