> CiteInPages is a set of Applescripts and templates that integrate BibDesk > with Apple's Pages word processor and is available at no cost under a BSD > license. > > Some users had reported an error in Snow Leopard that resulted in a premature > script exit with a "theCopy is not defined" message. This appears to be > related to an Applescript problem in Snow Leopard and a workaround is now > available that appears to avoid the problem in my testing. > > More information about CiteInPages and version 1.04 with the workaround are > available at http://jhh.med.virginia.edu/main/CiteInPages > > Jim Harrison > Univ. of Virginia > > ===Read only if you're interested in Applescript oddities=== > > If anyone has insight into why the fix works, I'd like to understand the > situation better. Briefly, the problem occurs during a scripted Finder copy > of the initial Pages word processing file. The file copy could be executed > successfully using the code from the script, if that code were put into a > separate small script. In the main script it looked like this: > > -- initial setup of BibDesk > -- initial setup of Pages > > -- tell Pages to capture the POSIX path to the current Pages document as text > in thisFilePath (done with a command from the Pages Applescript dictionary) > > tell application "Finder" > activate > try > set theCopy to duplicate file thisFilePath > ... > > The intent is for theCopy to receive a reference to the duplicated file and > then subsequent processing is directed to the duplicate. The duplication code > works fine in a small separate script, but in CiteInPages the duplicate > command failed. > > Eric Gilbert found that if a call to a dialog box requiring a click to > continue was inserted prior to the duplication command, the error > disappeared. In subsequent testing I found that a one second delay inserted > at the same spot also eliminated the error (at least in my environment). The > current workaround looks like this: > ... > tell application "Finder" > activate > delay 1 > try > set theCopy to duplicate file thisFilePath > ... > > Is it possible that the request to Pages for the file path initiates another > process that hasn't completed by the time the script hits the duplication > command and thus there's nothing in thisFilePath? That would require the > unbelievable circumstance of Applescript actually being faster than something > else. If that's the case, is there a reliable and safe way to block script > progress until the value comes back? Or am I barking up the wrong tree here.
Never mind. I am barking up the wrong tree. I still don't know what the problem is, but it's not incorrect or absent contents of thisFilePath. I'm happy to receive any comments or suggestions off list. Jim Harrison ------------------------------------------------------------------------------ _______________________________________________ Bibdesk-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bibdesk-users
