How do I wait for HandMorph>>openInHand to complete?

Trygve Reenskaug trygver at ifi.uio.no
Mon Aug 23 08:07:47 UTC 2004


Ploblem resolved!
The problem was that I want to do things after Morph>>openInHand has 
completed placing a new morph on a canvas. I have received some interesting 
pointers, but the short answer is that it cannot be done.

I believe I understand what is happening. Open an inspector on ActiveHand 
and select 'submorphs'. It is an empty Array. Keep the inspector open while 
you run this code in a Workspace:
   morph := Morph new. " create "
   morph openInHand.   " place "
   Transcript show: ActiveHand submorphs.

The morph is attched to the ActiveHand; you can see that its submorphs now 
includes it. The stack is actually 37 deep just after the openInHand:

1: (3840) UndefinedObject/DoIt {#(a Morph(3795))}
2: (2724) Compiler/evaluate:in:to:notifying:ifFail:
3: (709) TextMorphEditor/evaluateSelection
...
25: (2920) HandMorph/sendFocusEvent:to:clear:
26: (2920) HandMorph/sendEvent:focus:clear:
27: (2920) HandMorph/sendKeyboardEvent:
28: (2920) HandMorph/handleEvent:
29: (2920) HandMorph/processEvents
30: (3742) WorldState/doOneCycleNowFor:
31: (3258) Array/do:
32: (3742) WorldState/handsDo:
33: (3742) WorldState/doOneCycleNowFor:
34: (3742) WorldState/doOneCycleFor:
35: (905) PasteUpMorph/doOneCycle
36: (2445) Project class/spawnNewProcess
37: (283) BlockContext/newProcess

Activations return after the Transcript statement until ActiveHand gets 
control again (WorldState>>processEvents ?). ActiveHand with its attached 
morph is visible on the screen and follows the cursor until the user 
presses the red button. ActiveHand returns the morph to its real owner, 
removing it from its submorphs. You can see this if you put this trace in
      Morph>>privateOwner:
           Transcript show: aMorph.
           ...

The conclusion is that there is indeed a single input process. But the 
openInHand mechanism can only be understood by considering the stack. There 
is no way I can wait until morph has been positioned, because the 
positioning only starts after I have returned.

This very cool software leaves me cold. Since I do not want to do other 
things before the positioning completes, I replace it with a simple and 
transparent mechanism a la Rectangle>>fromUser

Cheers
--Trygve




Earlier mail:
>Karl, Ned,
>Many thanks for your suggestions. The following executed in a workspace 
>demonstrates the problem:
>
>    symbol := Morph new.              " create "
>    symbol openInHand.                  " place "
>    (ActiveWorld submorphs includes: symbol) ifFalse: [self error]. " Use. "
>
>This test fails. But the last statement does not fail if I select and doIt 
>after having placed the new morph.
>
>The problem is clearly non-trivial.
>
>I have tried waiting after the openInHand:
>   ActiveWorld doOneCycle.              " try to wait - 1. "
>    ActiveWorld doOneCycleNow.           " try to wait - 2. "
>    ActiveWorld runLocalStepMethods.     " try to wait - 3. "
>No help there.
>
>I have tried
>    symbol := Morph new.              " create "
>    symbol openInHand.                  " place "
>    WorldState addDeferredUIMessage:
>         [(ActiveWorld submorphs includes: symbol)   " use "
>                       ifFalse: [self error] ]
>No change.
>
>I'm running Squeak3.6-5429-full. There is no addedMorph: method in the 
>whole system. (It is a feature of 3.7)
>
>Morph>>intoWorld: runs when owner is set, but the morph is not yet 
>positioned. So it runs before openInHand returns. A halt shows that it is 
>in the same thread as the triggering menu command and openInHand. But the 
>positioning is independent of this thread and takes place while the halt 
>debugger is open.
>
>Amazing.
>--Trygve


-- 

Trygve Reenskaug      mailto: trygver <at> ifi.uio.no
Morgedalsvn. 5A       http://heim.ifi.uio.no/~trygver
N-0378 Oslo           Tel: (+47) 22 49 57 27
Norway

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20040823/c71615b4/attachment.htm


More information about the Squeak-dev mailing list