Re: Timing problem.
Re: Timing problem.
- Subject: Re: Timing problem.
- From: email@hidden (Michael Sullivan)
- Date: Tue, 13 Aug 2002 09:54:29 -0400
- Organization: Society for the Incurably Pompous
I wrote, oblivious to discussions that had happened on the list in the
last 24 hours, because, well, I hadn't downloaded them yet:
>
I know there's a way to do this because it's been discussed before, but
>
I can't seem to find it in the archive.
>
I have a production script that calls a function of a QuarkXT (made to
>
print), and then goes on to make changes to the document as clean up.
>
The idea is that I need the document to print in the state it is in when
>
I call that print job. The problem is that the Xtension (helpfully)
>
returns done very quickly, before it has actually done all it's
>
processing. This is cool in a way, because it allows one to go on to do
>
other things in the script while it's printing.
>
The problem is that what I want to do in the script next changes the
>
document, and does it fast enough, that what's there after the change is
>
what ends up being printed.
>
I've tried to insert a loops in the script to take up time, but they all
>
have the same effect as a "delay" which is to halt the app (and thus the
>
printing) entirely while it's running. So the printing conveniently
>
waits for all that rigamarole to be done with and for the changes to
>
happen, and *then* prints...
>
I'm sure I saw somewhere that there's a way to put in your script "wait
>
n seconds and let other stuff happen in the meantime", as opposed to
>
"bring the entire system to a screeching halt for n seconds", but I
>
can't for the life of me recall what it is, and I'm not finding it in
>
any of my references.
>
Any help?
Well, I have good news and bad news. The bad news is that none of the
suggestions I read this morning after sending off this message made the
slightest bit of difference in my problem. This included a number of
other things that I tried, including a non-destructive call to the very
same XT that was doing the printing. But there something happened that
twigged me. I had sworn that I had this script working perfectly fine
on another machine, and was wondering WTF had happened.
I *knew* that I had another variant of the script working where the
print job was called multiple times for different page ranges, which is
what led me to try calling the XT again just for a job list, figuring
that AS would then nicely wait for it to finish what it was doing, and
return one. When that didn't work, I went back and tried running with
multiple page ranges. Broke also, in fact this one actually errors!
And now for the good news: Suddenly I realized what my actual problem
was -- I am running these from OSAMenu, and on this new installation, I
had forgotten to check the "Don't fuck up all my scripts" box, which you
may know as "Run scripts more compatibly". Obviously whatever it is
that LR does in OSAMenu to run stuff faster does something roughly
equivalent to "ignoring application responses" around the whole script.
In any case, mea culpa for blithely ignoring yesterday's list activity
before posting, and it appears my problem is solved, though I'm still
interested to know whether there is such a command as "let the system
work for n seconds" and if not, why not and maybe it should be
considered for some future upgrade.
Or is there a consistent, robust way to do this that will *always* work
given the existing structure? I was trying to work out some way to use
"idle" for this purpose, but I can't figure it. I can have an on idle
for a stay open app, but if I were to call it from another script
(assuming I can), it would just run through it's idle loop once and then
*return*, right? So even if I'm waiting for a return, I'll get one
immediately without the called script ever actually idling. If I could
do a time check and send my original script back a message when it's
actually done, that would be great, as long as I can get my script to
idle waiting for that message. AFAICT, unless the message is the return
from a specific call to the app, my script will never actually idle. It
looks like the only way to get a script to idle, is with an idle
handler, which only works as a stay open applet which waits for the
*system* to call it.
This strikes me as possibly posing a problem at some point. If I ever
ran into an app that returned an answer too fast all on it's own, this
kind of construction might be necessary, no? Also, for some other
script, the time difference in how OSAMenu runs could matter enough that
I'd really care about being able to turn that checkbox off. What about
distributing scripts to people who might run them under OSAMenu -- it'd
be nice to be able to make them "less compatible" proof or nearly so.
Anyway, just musing at this point.
Michael
--
Michael Sullivan
Business Card Express of CT Thermographers to the Trade
Cheshire, CT email@hidden
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.