Hi Igor, I tried adding it outside of the addDeferredUIMessage as well: process := [ newMorph := aBlockWhoseValueReturnsAMorph value. WorldState addDeferredUIMessage: [...] ] newProcess. However, the problem seems to be the same. If you, or someone else, would have time to look into it, here is how to reproduce: Download the latest moose image: http://ci.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/artif... Run: | browser | browser := GLMTabulator new. browser column: #numbers. browser transmit to: #numbers; andShow: [:a | a list display: [:x | 1 to: x] ]. browser transmit from: #numbers; toWatcher; andShow: [:a | a list title: [:x | 'Large presentation for ', x asString]; display: [:x | x to: (x * 1000)] ]. (browser openOn: 42) left: 0; top: 0. (GLMWatcherWindow uniqueInstance toggleOpen) left: 300; top: 100 . Time millisecondsToRun: [ (browser panes first port: #selection) value: 10 ] . The relevant code is in GLMWatcherWindow>>addContent: The interesting thing is that if I print the amount of time, it goes fast (close to 0s), but the UI is still blocked. Cheers, Doru On 27 May 2012, at 04:23, Igor Stasenko wrote:
On 27 May 2012 01:58, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
process := [ WorldState addDeferredUIMessage: [ newMorph := aBlockWhoseValueReturnsAMorph value. self contentsMorph removeAllMorphs; addMorph: newMorph fullFrame: (LayoutFrame fractions: (0@0 corner: 1@1)) ] ] newProcess.
Sure thing, because you still building your morph in UI thread (inside a block which you pass to addDeferredUIMessage.
To make it clear, WorldState addDeferredUIMessage: can be rephrased as:
WorldState evaluateThisBlockInUIProcess:
So, moving newMorph := aBlockWhoseValueReturnsAMorph value. outside of this block will do the thing.
-- www.tudorgirba.com "Speaking louder won't make the point worthier."