Nicolas Zinovieff wrote:
>I don't think it's related to Java, actually. I've been sending scores
>of AppleEvents from C/ObjC programs to iTunes as well, and sometimes, if
>I'm too fast, the AppleEvent gets garbled or something, and the AE
>"decoder" crashes on the result...
>My guess is that there is some kind of race condition within iTunes that
>corrupts the AE stuff every once in a while.
One possible work-around is to put a time-delay between AppleEvents sent to
iTunes, like 10 ms or something. My approach would be to define the
interval with a system property, then tweak it until I found the point
where it stopped crashing or hanging, then back it off from that for some
safety margin.
I realize this is a totally empirical hand-tuned hack.
Another possibility is to use the 'osascript' command. However, that's
also introducing delays because of the time it takes to exec the process,
compile the script, etc. So even supposing it solves the problem, the
reason it works might be nothing more than the fact that it's added some
incidental delays due to overhead. But incidental overhead delays are
harder to control for than an intentional timed delay between events.
The only other thing I can think of is a daemon mediator written in
AppleScript, which you send events to from Java, and which it then forwards
to iTunes or Finder and then forwards replies back to Java. This is just
the Mediator design pattern writ large, as a kind of hacky inter-process
kluge-hammer. It still doesn't really answer the question. It just shifts
the burden from NSAppleScript and Cocoa-Java to a pure AppleScript daemon.
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
