Re: Filemaker 8.5 stored applescript problem
Re: Filemaker 8.5 stored applescript problem
- Subject: Re: Filemaker 8.5 stored applescript problem
- From: "Stockly, Ed" <email@hidden>
- Date: Thu, 17 May 2007 11:27:42 -0700
- Thread-topic: Filemaker 8.5 stored applescript problem
> If you have to test the code repeatedly in Script Editor or Smile the
interpreter will "pretty print" the raw code. That's not what we want.
Actually, that is what I want...
> However, comments aren't interpreted, so the comments will have the raw code.
I still don't get this, even if I type in the raw codes, they still convert
to appleScript, it seems this solution would only work using Filemaker's
script editing environment, is that right?
>>> handlers or libraries are not being recompiled on every run so it is not
necessary to replace the raw code each time you run through the script.
Again, is that in the Filemaker environment, because they do recompile in SD
after any changes.
>>> There's less typing in the raw codes method ;-)
Well, in Script Debugger, you can do this without typing, you simply click
the "paste tell" button in the applications palette. Plus, I can never
remember the key combination for the double chevron characters (probably
because I never use them).
> It is always slower even on a single run. The question is, "Does it matter?"
Exactly, I think we need to quantify how much slower it is to send an OSAX
command to an application that doesn't handle it.
>>> It is quite likely that the Finder is already busy (System Events is
probably twiddling it's fingers) so you immediately begin time sharing.
Again, with multi-tasking threaded aps in OS X, I don't think that even a
busy finder slows things down that much. That was the point in buying Next
and bringing back Steve and all that, right? To make AppleScripts run
faster?
I agree that System Events may be a better choice, but that should be tested
too.
>>>Apart from that, I like to think that code aggregates. If I build a handler
that uses the most efficient methods I'm confident that it will work well.
For me, I have scripts that I've written 10 years ago or more that I'm still
using and may have to tweak now and then and the last thing I want to do is
try and figure out what all those raw codes are. (Although I guess
commenting would help)
> I think what you probably found are the ³read² and ³write² constants for the
³access² enumeration
That's right, and that is where the terminology conflict comes...
>> I think the caveats in your advice support the use of ³open for access.² In
my experience I¹ve found that using OFA before calling read/write usually helps
avoid unexpected errors.
That may be true in some cases, but that's clearly not what's happening
here. In this case it's a terminology conflict, which we knew from the error
message the OP was getting, which was clearly a compile error.
>>>I believe that this is the reason OFA is used in all the read/write examples
in the AppleScript Standard Additions Guide...
I believe the reason open for access is used in the Standard Additions Guide
is that in the past it was required but it is no longer required and the
guide hasn't been updated.
using terms from application "System Events"
set file_path to "/var/tmp/myNewFile.txt"
set file_ptr to open for access ((POSIX file file_path) as reference)
with write permission
write file_path to file_ptr
close access file_ptr
end using terms from
If this solution works as well as enclosing the command in a tell, then it
may resolve the timing issue since it's not actually sending commands to
system events, although I'm not sure if it sends the commands to filemaker
anyway. Again, should be tested and timed, but that may be the best
solution.
ES
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden