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
|