On Friday 10 May 2002 12:28 pm, Ken Causey wrote:

> OK, I think I understand this solution.  But it has problems of
> another sort in my mind, encapsulation.  I want (unrealistically
> perhaps) to be able to use my object like:
>
> response := (InfoRequester new) usersResponse
>
> Where this simply returns the needed info, blocking until it is
> available. 

Except that you don't want to block the single Morphic thread, because 
if you do the UI will stop working and you'll never get your 
response.

I don't see an encapsulation problem. I tend to use explicit state 
machines for event handling (see my NCFSMMorph in Connectors for a 
good base class).

This helps manage otherwise complex user interactions.

There is no reason you can't construct a FillInTheBlankMorph, open it 
up, and poll its done flag in your Morph's step method.

Or fork off a watcher and then add a deferred UI message when done, 
like in the attached change set (untested).

> The host shouldn't have to contribute to this effort or
> understand how it is happening.  This is the design of
> FillInTheBlankMorph I believe.
>
> And perhaps, whether I like it or not, the result is
> FillInTheBlankMorph>>getUserResponse.

Well, the problem is that Morphic is basically single-threaded (think 
Windows 3.1 here).

So you have to keep the event handling and stepping going while you 
wait.

-- 
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FITBNonModal-nk.1.cs
Type: text/x-squeak-changeset
Size: 1366 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20020510/ff20f316/FITBNonModal-nk.1-0001.bin