• Choose a category
• All
• Classic-Fiction

Reply

Every interapplication communication (under normal circumstances) results in a reply from the target application. The reply is itself an Apple event.

This comes as something of a surprise to the naïve user. As human beings, we naturally tend to feel that there are, broadly speaking, two reasons for sending an interapplication communication: either we tell the target to do something or we ask the target a question. Therefore an interapplication communication can be thought of as either a command or a query . We expect a reply from a query—that's the purpose of the query—but not from a command. Under the hood, however, there is no real technical distinction here; either way, it's the same kind of message, and either way, there will be a reply.

What's the use of a reply from a command? Well, for one thing, even a command might result in some information useful to the sender. For example, the AppleScript make command creates a new entity—a document or a word, for example—but it also generates a reply, which is a reference to the newly created entity. That's useful because the usual reason for creating something is to do something with it, and it might be tricky to get a reference to the newly created entity otherwise.

There is also a solid technical reason why every interapplication communication generates a reply. Remember, these two applications are running independently, so they have to be coordinated somehow if they are to interact coherently. The sender, having sent a command to the target, typically doesn't want to proceed to its own next step until the target has finished obeying that command. The reply informs the sender that the command has been carried out (or, alternatively, that an error has occurred).

When two independently running applications communicate with each other, things can go wrong. The sender sends a message to the target, and then what? The target application might try to obey the message, and crash—leaving the sender in a state of limbo, waiting for a reply that will never come. The target might obey the message, but require a great deal of time to do so. The target might be busy or otherwise not in a position to receive the message in the first place. The sender needs a way to hedge his bets in order to cope with such possibilities. Apple events provide some bet-hedging mechanisms.

Timeout value

The sender may attach to the message a timeout value, a statement of how long he is willing to wait for an answer. If a reply doesn't come back within the specified time, the sender receives a reply anyway—a reply saying that, for one reason or another, no reply came back in time. Thus the sender has an opportunity to respond coherently to the situation. (Meanwhile the target is probably still performing his time-consuming task, blissfully unaware that the sender has lost interest.)

Ignore reply

The sender may signal up front that he won't be interested in the reply (presumably this is a command, not a query); he doesn't care to know what the reply is or whether there is one, or even whether the command was carried out. In this case the sender does not wait; the message is sent, and the sender immediately proceeds to the next step of his own process. The sender will never find out in any direct way what became of the Apple event. This devil-may-care approach is rather rarely used, but there are times when it comes in very handy.

Scriptability

Not just any old Apple event can be sent to any old application. Well, it can, but the result could easily be an error message instead of the desired result. The target application needs to have been constructed in the first place in such a way that the particular Apple event you send is one to which it is prepared to respond. Such an application defines internally a repertory of Apple events that it understands. The application is then said to be scriptable .

The thing to understand clearly here is that a scriptable application is scriptable just with respect to the particular repertory