The problem is really not related to Apple events. As an example, take the
same script and field and try sending them to another stack without using
Apple events (send "blah blah blah" to stack "blah"). You will find that
returns can not be part of a string parameter when sent to another stack.
Therefore the problem is caused by this constraint and not by an Apple
event constraint.
Here are two recommendations for avoiding the problem.
First, create an "on AppleEvent" handler at the stack level of the
receiving stack. With this created you simply send the whole field to your
receiving stack.
on mouseUp
send cd fld "data" to program otherApp
end mouseUp
When the "AppleEvent" handler is activated in your receiving stack, you
simply extract the contents of the sent field from the "data" parameter and
put it into your location field.
on AppleEvent
request AppleEvent data
put it into cd fld "myField"
end AppleEvent
The only problem with this solution is that all Apple events will be
trapped by this handler. If you are only planning on sending one Apple
event or you are willing to parse out all potential Apple events in this
handler, this solution is OK. If not you might want to try the next
solution.
Using the same "incoming" handler you presently have, change the nature of
the "data" parameter to represent the id (or number or name) of the field
in the sending stack which holds the data. Then, in the "incoming" handler
request the contents of this field from the sending stack. For example:
on incoming data
request data from program sendingProgram
end incoming
The script you would use in the sending stack would look something like this:
on mouseUp
answer program ""
put it into otherApp
send (incoming & quote & "cd fld id 1" & quote) to program otherApp┬
without reply
end mouseUp
This article is adapted from the Claris Tech Info database.
Support Information Services