Nice demo, Alain. After some more testing, what I'm working on works too,
partly.

Here's the "partly" part (it will take some explaining). In CGIs, the
AppleEvent is initiated by the server software (WebStar, in my case), and it
eventually expects a reply. FBR7 doesn't have a global defined for the
AEReply, so I modified the SubsAppearanceAppleEvents.incl to provide me with
a global reply descriptor called gFBAEReply that my AppleEvent handler can
nab and store away for later. So far so good.

_Before_ launching the thread, the AppleEvent has to be suspended, like so:

OSErr% = FN AESuspendTheCurrentEvent(t.theAEvtPtr)

["t" is my record structure for storing away the AppleEvent information. A
pointer to it gets passed in as a parameter when the thread is created, like
so: threadbegin fn ThreadHandler,t.]

Then the thread gets created, and when my thread handling function gets
called, it generates the response, and then resumes the original AppleEvent,
like so:

OSErr% = FN AEResumeTheCurrentEvent(@procAEvtPtr, @procAEvtReplyPtr,0,_nil)

[where the "proc" variables are the AE info that was retrieved from the "t"
record].

When the Apple Event is resumed, the result is returned to WebStar. All of
that works fine, no memory leaks, rock solid, been working for years.

The kicker is this, though. Placing "abort=ThreadStatus(120)" in various
places in the threadhandler routine (for testing) leads me to suspect that
between the suspending and the resuming, no new AppleEvent is accepted from
WebStar by the runtime.

Does that make any sense? If I comment the two AppleEvent statements out
along with the FN AEPutParamPtr call that stores away the reply, the
threading works as expected, like clockwork. If the AppleEvent is suspended
and then resumed, new WebStar AppleEvents aren't even vectored to AppleEvent
handler until the old one has been resumed. At least that's the way it looks
to be behaving.

Any ideas, anyone?

--Steve


On 9/30/02 2:54 PM, "Alain Pastor" <pixmix@...> wrote:

> 
> 
> Alain Pastor wrote:
>> 
> 
>>> 
>>> I know that it _will_ work because I've done the coding by hand with
>>> toolbox
>>> calls. I'll do some more testing and report back. If anyone has any
>>> enlightenment to share, TIA.
>>> 
>> 
>> I have no enlightenment to share, but I'm interested to hear more about
>> your testing. I don't see why your scenario do not work.
>> 
> 
> My test, which mixes two examples found on the CD, indicates that your
> scenario works. Here are the two modified programs I have used:
> 
> This one will send three AppleEvents:
> 
> // ========================
> begin globals
> dim gCount
> end globals
> 
> run "Simple Thread.app"
> 
> local fn doTimer
>  inc(gCount)
>  long if gCount < 4
>    SendAppleEvent _"Andy", _"TEXT", , , "Simple Thread.app"
>  end if
> end fn
> 
> window 1, "Test"
> 
> on timer (1) fn doTimer
> 
> do
>  handleevents
> until gFBQuit
> // ========================
> 
> 
> That one, that you must build, will receive the AppleEvents and launch
> the threads:
> 
> // ========================
> output file "Simple Thread.app"
> 
> begin globals
> dim gWnd
> end globals
> 
> local fn threadedFunction
>  dim x, abort
>  dim txt as str255
>  dim r as rect
>  dim oldOutput, thisWnd
> 
>  oldOutput = window(_outputWnd)
> 
>  inc(gWnd)
>  thisWnd = gWnd
>  SetRect(r, 20,40,400,300)
>  OffsetRect(r,(r.right - r.left)*(gWnd - 1),0)
>  window thisWnd,"Window" + Str$(gWnd),@r
>  edit field 1,"Type here while thread runs",¬
>            (16,100)-(window(_width)-16,120)
> 
> 
>  txt = "This is a thread that is running in the background."
>  text _sysFont,12,0,0
>  for x = 1 to txt[0]
>    window output thisWnd
>    print@(1,1) left$(txt,x)
>    window output oldOutput
>    if threadstatus(10) != _noErr then exit fn
>  next
>  window output thisWnd
>  print@(1,2) "Thread complete."
>  window output oldOutput
> end fn
> 
> 
> local fn doAppleEvent
>  threadbegin fn threadedFunction
> end fn
> 
> on AppleEvent( _"Andy", _"TEXT" ) fn doAppleEvent
> 
> do
>  handleevents
> until 0
> // ========================