Re: Hoe to tell when a program is done?
Re: Hoe to tell when a program is done?
- Subject: Re: Hoe to tell when a program is done?
- From: kai <email@hidden>
- Date: Sun, 27 Mar 2005 16:34:59 +0100
On Fri, 25 Mar 2005 09:41:39 -0800, Dennis Jones wrote:
I use LineBreak to convert a number (6 to 10) of files from DOS style
end of line characters to Mac style. However, using the code below,
the program quits before it finishes processing all the files in the
'sourceFolder'.
How can I determine LineBreak is done before I quit the program?
I could use:
do shell script "sleep 10" or
pause 10
but as previous posts have noted, these use lots of cycles and I would
not be assured the program had finished processing, or I would waste
lots of time.
-- code
on Run_LineBreak(sourceFolder)
tell application "LineBreak"
activate
open sourceFolder
quit
end tell
end Run_LineBreak
You've raised a couple of questions here, Dennis.
First, there's the issue of delaying 'tactics'. I don't particularly
want to disagree with any advice that you may have read previously,
although my experience suggests that some methods aren't nearly as
cycle-hogging as one might be given to believe.
In terms of waiting techniques, the heaviest drain on CPU cycles will
almost certainly come from an uninterrupted repeat loop (i.e. one
containing no delays). A recent test here returned a figure for this of
70%+. (OK for a momentary burst, I suppose - but undesirable over a
prolonged period.) Interestingly, the Standard Additions 'delay'
command syphoned off between 60% to 70% of cycles when run from Script
Editor - but no more than 5% when run by an applet or by System Events
(i.e. from the Scripts menu). The cycles used by a "sleep" shell
script, or an idle handler, were negligible. (For a stay-open app, I'd
personally favour an idle handler - since it seems rather more
receptive to interruption.)
That said, I share your inclination to avoid blind delays wherever
possible. As you've already observed, the time allowed needs to be
longer than that generally required - just in case of an occasionally
lengthier operation. So, in many cases, the script will linger longer
than is really necessary. Far better if it can respond as soon as a
particular condition occurs.
Which brings us to your other question - that of how to determine when
LineBreak has actually finished processing the target folder's contents:
My first thought was to use GUI scripting to monitor the value of
LineBreak's progress indicator - although, once the application has
started processing files, this seems to be problematic. However, the
difficulty experienced in interrupting the processing operation
provides a further possibility to explore...
Now it might sound strange but, instead of the application quitting
before it has *finished*, I wonder if it's actually quitting before it
has *started* processing items. I get the impression that, when it sees
a quit command, LineBreak interrupts its current activity and just
quits. However, once processing has started, it seems to behave more
'normally' - and finishes the job in hand first. (I gave it a batch of
a couple of hundred files, in nested folders, to process - which it was
evidently quite happy to complete before quitting.)
If that's the case, the challenge is simply to get LineBreak started on
the file processing operation before it gets around to considering the
quit command. I tried a 1 second delay to give it enough time to do
this, and that appears to work fine here - apart from occasionally
introducing a secondary problem. Again, this seems to be caused by
LineBreak's keenness to quit at the first opportunity...
If file processing takes less time than the delay, then LineBreak
apparently quits before the delay period has expired - causing an error
number -609 (invalid connection). If you're in Panther, you could try
reducing the delay to a value of slightly less than a second, but you'd
need to make sure that it doesn't fall below the time LineBreak needs
to start processing. It's probably safer to just suppress reporting of
the error, by wrapping the quit statement in an 'ignoring application
responses' or 'try' block.
Finally, for situations in which file processing may take some time,
you could move the LineBreak window to the dock while it does its work.
I've therefore added an optional miniaturizing statement to this
suggested variation of your handler:
----------------
on Run_LineBreak(sourceFolder)
tell application "LineBreak"
set miniaturized of window 1 to true (* optional *)
open sourceFolder
delay 1
ignoring application responses
quit
end ignoring
end tell
end Run_LineBreak
----------------
Incidentally, if you continue to have problems (or even if you don't -
since the above suggestion is a bit of a workaround), you might like to
consider contacting Josh Aas of Trance Software, who may be interested
in some of the points raised in this discussion:
Email:
email@hidden
Website:
http://www.trancesoftware.com/
---
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