ned at squeakland.org
Thu Dec 16 06:53:10 UTC 2004
[sorry, sent the prior too soon with a bad keystroke]
On Wednesday 15 December 2004 6:12 pm, Frank Caggiano wrote:
> I'm somewhat confused by this method. I can't see why
> FillinTheBlankMorph needs to run it's own version of the World's event
Pretty much every modal dialog does so. The reason is that the code is called
inline; that is, the Morphic thread that creates the FITB morph wants to wait
until that blank is filled in.
Since there is only one Morphic thread, we have to turn the event handling
inside-out and create our own mini-event loop.
This is also done for e.g. menus and other dialogs.
Otherwise, there would be no way to wait for completion.
Now, some might argue that the event handling thread needs to be separated
from the Morphic stepping thread; however, this would complicate the code
> Also the ProvideAnswerNotificatiion signal: bit of code has me stumped.
That appears to be a recent addition that would let you run a block of code
and automatically respond to user interaction requests.
Here's the clues you need:
ProvideAnswerNotification signal: something
will return whatever the exception handler (if any) returns.
So if in an outer scope (a caller up the stack somewhere) you have a handler
[ FillInTheBlankMorph request: 'whatever' ]
do: [ :ex | ex return: 'response' ]
then you could run code and not have to worry about being interrupted for user
> Any and all enlightenment will be rewarded by 100 bucks US; well not
> real US bucks, sort of Squeak community bucks, say I'll be your code
> monkey for a week :-)
I could stand one of those...
More information about the Squeak-dev