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.  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.

Ken

On Fri, 2002-05-10 at 14:20, Ned Konz wrote:
> 
> Actually, you don't want to fork. The problem with forking is that you 
> can't fork a dialog box from a non-UI thread.
> 
> Imagine this:
> 
> Someone hits a button or something that makes your Morph want to get 
> data from the user.
> 
> Your Morph constructs a dialog box with an entry field and a couple of 
> buttons. The OK button (and accept in the text field?) is wired so 
> that it calls a userInput: method in your main Morph.
> 
> Your Morph notes that it is waiting for data. It may also disable 
> other UI elements so that the user doesn't get confused.
> 
> When the callback occurs (when your Morph's userInput: method is 
> called), your Morph knows that it is waiting for data for a 
> particular reason. It takes the user data and continues doing what it 
> needed the user input to do.
> 
> -- 
> Ned Konz
> http://bike-nomad.com
> GPG key ID: BEEA7EFE
> 
>