FillinTheBlankMorph>>getUserResponse

Frank Caggiano frankcag at crystal-objects.com
Fri Dec 17 16:25:42 UTC 2004


Ned,

Thanks for the response. I'm still digesting it and going through the 
code.

So if I understand it so far, the normal action of FITB morph is to 
block the caller until either the accept/cancel or possibly the enter 
key is hit. Now the call in FITB morph to doOneCycle is to keep us 
alive/responsive or to keep the whole world we're part of 
alive/responsive?

In the case of the 'ProvideAnswerNotification' section and your code 
example using it, can it be said that  this is analogous to 
setjmp/longjmp in C?  I tried using your example from a workspace 
(bracketed by calls to Transcript show: to see if the call blocked or 
not) and it didn't seem to work.
I did :

Transcript show: 'Going in.'; cr.
  [ FillInTheBlankMorph request: 'whatever' ]
  on: ProvideAnswerNotification
  do: [ :ex | ex return: 'response' ].
Transcript show: 'Gone.';  show: r; cr

'Going' and 'Gone' got written to the Transcript and the FITB morph 
appeared as would be expected in a non-blocking scenario  but the 
accept button  only caused the TextPane morph to flash not return and 
the cancel button didn't do anything,  Interestingly this is the same 
behavior the FITB morph exhibits if you have one open when you leave a 
project and then return to that project. (Which is the bug  that got me 
going on this in the first place).


(You didn't think earning a code monkey would be easy, did you?)

regards
------------------------
Frank Caggiano
frankcag at crystal-objects dot com
http://www.crystal-objects.com

The best education for the best is the best education for all.
					Robert Maynard Hutchins




More information about the Squeak-dev mailing list