Re: R23's Osaxen Rant (or much too much ado about nihil)
Re: R23's Osaxen Rant (or much too much ado about nihil)
- Subject: Re: R23's Osaxen Rant (or much too much ado about nihil)
- From: Paul Berkowitz <email@hidden>
- Date: Fri, 26 Jan 2001 09:05:05 -0800
On 1/26/01 1:55 AM, "Bill Cheeseman" <email@hidden> wrote:
>
In this case, it isn't the Finder's "fault," so to speak; you just didn't
>
write your script to make full use of the Finder's implementation of file
>
copying. All you have to do is write a handler that delays until the
>
Finder's copy operation is complete, using the "bzy " file type mechanism
>
that was introduced a few versions ago. Examples exist in Sal's help
>
modules.
>
>
The notion here is that a time-consuming process like a Finder copy can run
>
in a background thread so that your script can do other things in the
>
meantime. This can be useful. It's one of the powerful features of Finder
>
scripting. If the only thing you happen to want to do is the copy, then just
>
run your custom delay handler until the copy is done. Using the Delay
>
command in a repeat loop in your delay handler allows the rest of your
>
machine to function in the meantime.
That sounds like a very good idea, Bill. Thanks for writing in. You're
correct in that I have never investigated the "bzy " property. In many of my
scripts, I'm already using Akua for something non-Finder in nature, so I'm
not sure I'd gain anything by using the Finder, a delay handler, and
waiting, rather than a simple Akua command, but I'll certainly look into it.
In my present case, I don't want the script to do anything in the meantime
of course, since it can't do anything until it can find the file again.
In this most recent case, it's a little more puzzling. I have Jon's moveFile
or copyFile move or copy the file (because of this identical problem
earlier when I had used the Finder to do this without accessing "bzy "). I
then set the variable 'txtFile' to this file. Then I open it for access,
read it and close it using the access number. [This is what it couldn't do
at the earlier stage of the script: it couldn't find the file to open for
access. But using Jon's to do the copying it can. Interestingly, the script
sometimes also failed with Jon's moveFile, but never with copyFile.] Then
it does some text manipulation on the read text. Then it opens a different
file for access, writes this text to it, closes it. Then, in a try block,
it tells FileMaker Pro to do an FMP script which imports the second file,
whose name it knows. After all that, it tells the Finder to label the first
file green, to indicate that there was no trouble with the FMP import. (If
there was an error in the FMP step, then the on error segment tells the
Finder to label the file red and to send out an alert emali message.) And
that's where the script fails. It's a little puzzling, since the file
copying was done so many stages further back: it can't possibly still be
doing that. Instead it's either that it can't translate the alias or
(system) file format in which the alias knows the file (most unlikely) or
somehow it still considers the file busy after its open for
access/read/close access many stages back. All the activity has been on the
second file since then, not the first file. But somehow the 'close access',
even though I used the file access reference number to do so, has not
"worked" as far as the Finder is concerned, I guess. Here's that section of
the script:
---------------------------------------
try
moveFile txtFile to attachFolder -- Jon's
on error
set newFile to copyFile txtFile to attachFolder replacing
yes
deleteFile txtFile
set txtFile to newFile
end try
set f to open for access txtFile
set r to read f
close access f
if whichType "csv" then
set ls to {}
set num to ((count paragraphs of r) - 1)
repeat with k from 1 to num
set p to paragraph k of r
set end of ls to (p & tab & txtFileName)
end repeat
set AppleScript's text item delimiters to {return}
set r to "" & ls & return
set AppleScript's text item delimiters to ods
else
set AppleScript's text item delimiters to {"\""}
set lr to text items of r
set AppleScript's text item delimiters to {""}
set r to "" & lr -- remove quotes
set ls to {}
set num to ((count paragraphs of r) - 1)
repeat with k from 2 to num
set p to paragraph k of r
set end of ls to (p & "," & txtFileName)
end repeat
set AppleScript's text item delimiters to {return}
set r to "" & ls & return
set AppleScript's text item delimiters to ods
end if
set cfp to ((attachFolder as string) & "Current File")
--attachFolder is a previously defined folder as alias
set cf to open for access alias cfp with write permission
set eof cf to 0
write r to cf
close access cf
------------IMPORT TO FMP------------------
try
tell application "FileMaker Pro"
if whichType = "ss" then
set dbName to "shippingLog.fmp"
set dbScriptName to "ImportShippingLog"
else if whichType = "sr" then
set dbName to "ReceivedLog.fmp"
set dbScriptName to "ImportReceivedLog"
else if whichType = "csv" then
set dbName to "shippingChargeLog.fmp"
set dbScriptName to "Import"
end if
show window dbName -- might error here
tell database dbName
do script (FileMaker script dbScriptName)
end tell
end tell
tell application "Finder" to set label index of txtFile to 6
on error
--etc. set label index to 2, send an alert email message
end try
---------------------------------------------
Why does that last (Finder) line fail - frequently, about two-thirds of the
time, not always - and why should:
set ei to extended info for txtFile -- Akua
set label number of ei to 6 -- Akua
apply catalog info ei to txtFile -- Akua
always succeed (so far)? (Just to be safe, I'm putting it in a try block.)
--
Paul Berkowitz