Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!bu-cs!dartvax!eleazar.dartmouth.edu!earleh
From: earleh@eleazar.dartmouth.edu (Earle R. Horton)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Modeless dialogs, what am I doing wrong?
Message-ID: <14466@dartvax.Dartmouth.EDU>
Date: 18 Jul 89 04:34:20 GMT
References: <1484@ndmath.UUCP> <14455@dartvax.Dartmouth.EDU> <8029@hoptoad.uucp>
Sender: news@dartvax.Dartmouth.EDU
Reply-To: earleh@eleazar.dartmouth.edu (Earle R. Horton)
Organization: Thayer School of Engineering
Lines: 27

In article <8029@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes:
>In article <1484@ndmath.UUCP> milo@ndmath.UUCP (Greg Corson) writes:
>>What do I have to do to get the cursor to blink normally in the EditText
>>items of a modeless dialog?
>
>In article <14455@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu
>(Earle R. Horton) writes:
>>	DialogPeek xyzzy;	/* Points to your Modeless dialog. */
>>
>>	TEIdle(xyzzy->textH);
>
>That will work, but a better way is to call DialogSelect in response
>to null events.  I have philosophical objections to using DialogPeek.
>After all, why be low level when you can be high level?

     Well, that seems to work too.  I suppose your method is the
better one, being high level and all.  One thing puzzles me though.
Nowhere can I find actual Apple documentation on how to do this, or
even a hint that I should do anything with null events except toss
them.  I looked at the description of IsDialogEvent() just now, and
just maybe you could interpret it to mean that the function wants to
look at null events, but then again, maybe not.

     It looks to me as if this is one case where you have to guess how
to make it work, and TEIdle() was my first guess.

Earle R. Horton