Re: App and droplet
Re: App and droplet
- Subject: Re: App and droplet
- From: kai <email@hidden>
- Date: Wed, 18 Oct 2006 19:09:59 +0100
On 13 Oct 2006, at 22:14, Axel Luttgens wrote:
Thanks a lot, Kai, for having taken the time to reply in such a
detailed way!
I was more concerned with those seemingly differing behaviors
between an AS app (as built with SE) and and an AS Studio app, as
far as the handling of pending events is concerned.
With an AS app, it seems that the handlers for pending events are
executed each in turn.
With an AS Studio app, it seems that a kind of parallelism may be
observed: the execution of the handler for event B seems to be
intermangled with the execution of the handler for event A, even if
event A occured before event B.
Indeed, Axel. This behaviour is quite apparent during an
application's startup sequence.
The triggering of a handler that occurs later in the sequence is
evidently not delayed while execution of those preceding them is
completed. This can be demonstrated by inserting dialogs into various
handlers. During the early stages of the startup sequence, several of
these dialogs (e.g. those from the <will finish launching>, <open>
and <will become active> handlers) may be displayed at the same time.
They usually appear, however, in the expected order - and those that
appear later need to be dismissed before the earlier ones.
And this is why, I guess, you suggested following workaround:
set WasActivated to GotActivated
Exactly. The idea was to capture the value of the 'GotActivated'
property right at the beginning of the open handler - before it could
be changed by a subsequent handler.
I was thus more precisely wondering whether one could always
reliably rely on that precise moment: the execution of a handler's
first statement for catching an inter-event condition, such as the
setting of a property (in this case, GotActivated).
After a fair amount of testing, I'd be fairly confident of it -
albeit with some caveats...
You might recall the sequence I gave earlier, for an app that
included an open handler, which started:
1: will finish launching
2: awake from nib
3: launched
4: open
5: will become active
6: activated
Certain events, such as the displaying of a dialog, can evidently
affect this sequence - presumably because such an action causes the
app to activate. While it's probably not a good idea to introduce a
dialog too early in the startup sequence anyway, the following
examples might serve to demonstrate this behaviour. They show the
handler that contains the dialog in each case, as well as the
handlers that are called as a consequence (*during* its execution).
--------------------------–
1: will finish launching
display dialog
2: open
3: will become active
4: activated
5: awake from nib
6: launched
--------------------------–
1: will finish launching
2: awake from nib
display dialog
3: open
4: will become active
5: activated
6: launched
--------------------------–
1: will finish launching
2: awake from nib
3: launched
display dialog
4: open
5: will become active
6: activated
--------------------------–
1: will finish launching
2: awake from nib
3: launched
4: open
display dialog
5: will become active
6: activated
--------------------------–
In the case of the double-dialog example that I used earlier, the
<will become active> and <activated> handlers kick in between the
first dialog and the second:
--------------------------–
1: will finish launching
2: awake from nib
3: launched
4: open
display dialog 1
5: will become active
6: activated
display dialog 2
--------------------------–
Since the value of the 'GotActivated' property was changed during
execution of the <activated> handler, this might help to explain why
the two dialogs displayed different values.
Hence my question about a documented -"official"- statement about
such matters (which I haven't found yet).
Nor I, yet. Possibly the closest I've got so far is an old, passing
reference (in response to a previous issue) suggesting that
AppleScript won't start handling events until an AppleScript Studio
app is fully initialised:
http://lists.apple.com/archives/applescript-studio/2002/Feb/
msg00262.html
Like you, I'd feel a bit more comfortable with a little more detail
on all this...
:-)
(Apologies for the delayed response on this - caused by a brief
absence.)
---
kai
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden