Robert Purves wrote:
>
> Yoshiyuki Hasegawa wrote:
>> 1. Two code Alpha and Beta are separately compiled.
>> 2. Two programs are booted.
>> 3. "Send" button is alternately clicked.
>>
>> As for the demonstration program, the occurrence of the bug is  
>> fewer than an original program.
>> The bug might not occur in the first boot. They are quit and it  
>> boots it again at that time.
>> OS is restarted to reproduce the bug or it might have to be  
>> recompile as for the programs.
>
>
> I confirm that this statement sometimes hangs or freezes for a  
> minute or so, in OS X 10.5:
> SendAppleEvent clas, _"TEXT", @s + 1, len(s)
>
> With no 5th parameter for SendAppleEvent, you are broadcasting the  
> AppleEvent to all processes.
> In runtime FBSendAppleEvent, the AE is sent to all processes  
> discoverable by GetNextProcess(). A little debugging shows that the  
> delay is associated with AESend() to a process "mdworker". It  
> remains a mystery why mdworker is a bad target for AESend().
>
> The best cure is to target your AE instead of broadcasting it. Add  
> the appropriate 5th parameter to SendAppleEvent:
> SendAppleEvent clas, _"TEXT", @s + 1, len(s), "Test Program Beta"
> SendAppleEvent clas, _"TEXT", @s + 1, len(s), "Test Program Alpha"
>
>
> If you must broadcast, you will have to edit runtime  
> FBSendAppleEvent (in Subs Appearance AEvents.incl), to reject the  
> unhappy target mdworker.
> Change:
> long if ( toNamePtr == 0 ) or ( toName == processName ) // send to  
> all or thisPSN
> To:
> long if ( toNamePtr == 0 and processName != "mdworker") or ( toName  
> == processName ) // send to all or thisPSN
>

Thank you for help Robert.

The name of the application that wanted to send the event to the  
fifth parameter was set and the problem was solved.

The FB applications are working by my Intel Mac OS X 10.5 without the  
slow down.

Please give my best regards to advice concerning the conversion code  
to FBtoC continuation.

Yoshiyuki