Re: Hoe to tell when a program is done? - Solved
Re: Hoe to tell when a program is done? - Solved
- Subject: Re: Hoe to tell when a program is done? - Solved
- From: Dennis Jones <email@hidden>
- Date: Mon, 28 Mar 2005 20:52:05 -0800
Kai
Thanks for your evaluation of how LineBreak works. The code you
suggested worked just fine.
Dennis
On Sun, 27 Mar 2005 16:34:59 +0100, kai <email@hidden> wrote:
>
> 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
>
>
--
Dennis Jones
email@hidden
_______________________________________________
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