First of all to understand how applications runs inside a desktop you have to understand a desktop and applications but also processes.
The whole desktop (something like Mac OS X) is an collections of servers that creates an environment of a background, menus, applications, windows etc. A process can make use of the programming interface (API) of the desktop to make itself accessible in the desktop by creating windows for example. This whole presentations of the proccess inside the Desktop are called application.
As you may expect there are two forms of launching, the process and application. First the process is launching which is done quite fast, it’s procedural so in fact it is launched the minute it starts executing the first line of code. In the world of Unix, where everything is a process and no such thing as applications exists, the application is finished launching and not in a busy state quite fast. So, we don’t have to look in the world of Unix if an application is busy in the desktop.
When the process wants to run also as an application in the Desktop we have an second stage of launching. This however is more an initializer than actually launching an process/application. The process opens an interface with the desktop and is registering itself to the desktop (somewhere at this moment the application icon starts jumping in your Dock). After that (after creating an NSApplication object) a method is called from the Desktop willFinishLaunching where you can initialize your application. In Objective-C applications this is where you normally start writing your code. This method is actually called to tell the process that the process is successful connected to the desktop and the application object is created successful too.
Now we know how these two stages of launching an application works we can start figuring out what went wrong. We know that AppleEvents are send on process level through the kernel. So your script is sending the event to the AppleEvent manager and then the event manager is sending the event to the process or set the event in a queue and wait for the previous event to be finished. By default, when an application object is created and launching is completed, it will tell the event manager to be ready to receive events. It seems that in the application it doesn’t work that way and somewhere during launching (or launching of the application is not done in the willFinishLaunching method) the application accepting events while it’s not ready.
I’ve seen similar applications with the same problem and basically the only thing you can do is sending an event to the application. Note that getting the name from of the application is not sending an event to the application like many other standard commands. So getting window names won’t work either. To send an real event you need to send an Application specific command. For instance getting the state of a specific object that always exists after it’s completely launched.
To check if the Finder is completely launched I can use something like this:
set bootVolume to text 1 thru -2 of (POSIX file "/" as string)
tell application "Finder"
set attemps to 0
repeat
try
if name of first folder = bootVolume then exit repeat
end try
set attemps to attemps + 1
if attemps = 40 then # Application is not respoding for 20 seconds
error "Application is not responding" number 2
end if
delay 0.5
end repeat
# Application is repsoning; continue
end tell
When the Finder is abruptly quit (the first line of the tell finder block is quit) you’ll see that the finder is not responding properly and the method above will wait 1 or 2 attempts before continuing it’s code. The only thing you’ll need to do is find the proper “test” command for your application.