Important: The information in this document is obsolete and should not be used for new development.
Writing a Reply Filter Function
If your application callsAESend
and chooses to yield the processor to other processes while waiting for a reply, you can provide an idle function to process update, null, operating-system, and activate events, and you can provide a reply filter function to process high-level events. The previous section describes how an idle function processes events.Your reply filter function can process any high-level events that it is willing to handle while waiting for a reply Apple event. For example, your application can choose to handle Apple events from other processes while waiting. Note, however, that your application must maintain any necessary state information. Your reply filter function must not accept any Apple events that can change the state of your application and make it impossible to return to its previous state.
A reply filter function must use this syntax:
FUNCTION MyReplyFilter (VAR event: EventRecord; returnID: LongInt; transactionID: LongInt; sender: AEAddressDesc): Boolean;Theevent
parameter is the event record for a high-level event. The next three parameters contain valid information only if the event is an Apple event. ThereturnID
parameter is the return ID for the Apple event. ThetransactionID
parameter is the transaction ID for the Apple event. Thesender
parameter contains the address of the application or process that sent the Apple event.Your reply filter function should return
TRUE
as the function result if you want to accept the Apple event; otherwise, it should returnFALSE
. If your filter function returnsTRUE
, the Apple Event Manager calls theAEProcessAppleEvent
function on behalf of your application, and your handler routine is called to process the Apple event. In this case, make sure your handler is not called while it is still being used by an earlier call.