Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×

This topic is 3820 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Posted

hoping someone might be able to help me here.  here's the basic story, i do a lot of applescript work inside of my filemaker databases.  and over time, i've come to HATE having to convert all of my applescripts to calculated applescripts inside of filemaker simply because i always end up missing a quote mark somewhere, or a slash, etc.  so i have to go back through all the code and diagnose.  so, i came up with the idea to build an applescript conversion database.  you paste in the code, and poof, the calculated script spits out.  it works like a champ for the applescript to filemaker conversion.  now i'm working on the reverse so that if i need to take an calculated applescript back into applescript editor, it will drop all of the extra quotes and slashes.  i've gotten it to work, but i can't seem to get it to drop the very first quote mark of each line.  does anyone have any ideas as to how i can get it to recognize that there's a quote a the beginning of the line and remove it?  can't substitute or filter it because there are other quotes that need to stay.

 

 

ideas?

Posted

Wouldn't it be simpler to calculate the AppleScript in a variable?

 

You can pass that variable to Perform AppleScript, or copy the already calculated code (fit to be used with the AppleScript Editor) e.g. from the variable in the Data Viewer or after writing it into a field.

Posted

it is in a variable.  

 

 

this is what i'm using to get from applescript to filemaker:

 

""" & Substitute ( Applescript ; [""" ; """] ; ["¶" ; "" & ¶ & ¶ ""] ) & """

 

 

and from filemaker to applescript:

 

Substitute ( Filemaker ; [ """ ; """ ] ; ["" & ¶ &" ; ""] )

 

 

but that leaves the first quote mark in each of the lines.  can't figure out how to get them out.

Posted

You didn't understand what I suggested:

 

If e.g. you have a script with 

Set Variable [ $AS ;
List (
 "set myDoc to ((path to desktop) & " & Quote ( "someFolder:someSubFolder:someFileName.txt" ) & ") as text" ;
  "tell application " & Quote ( "TextWrangler" ) ;
    "activate" ;
    "open myDoc" ;
    "tell document 1" ;
      "set encoding to " & Quote ( "Unicode (UTF-8)" ) ;
      "close saving yes" ;
    "end" ;
  "end"
) ]
Perform AppleScript [ $AS ]
 
then after the Set Variable step, the variable $AS will hold the calculated code (without the indentations):
 
set myDoc to ((path to desktop) & "someFolder:someSubFolder:someFileName.txt") as text
tell application "TextWrangler"
  activate
  open myDoc
  tell document 1
    set encoding to "Unicode (UTF-8)"
    close saving yes
  end tell
end tell

which you could copy and drop directly into the AppleScript Editor (instead of executing the Perform AppleScript step).

 

And I suggest – as you can see in the sample – to use List() and Quote() when calculating AppleScripts; IMO, it looks nicer and makes changes easier. 

Posted

oh, i see what you're saying.  yes, that would be great except i would be doing these conversions long after they were implemented into the database.  so the variable wouldn't hold after quitting the database.  basically, if 3 months from the time i originally did the script, i needed to edit it and bring it back into applescript editor, that wouldn't work for me.  that's why i created a separate 'conversion' database that i just copy and paste into and out of.  

 

 

....did that make sense?

Posted

oh, i see what you're saying.  yes, that would be great except i would be doing these conversions long after they were implemented into the database.  so the variable wouldn't hold after quitting the database.

 

No, it wouldn't – but the script with the Set Variable step that has the code calculation still exists; you've simply moved that FileMaker code from the Perform AppleScript step into the Set Variable step. This allows you to grab the AppleScript code before it's passed to AppleScript interpreter (whereas Perform AppleScript behaves like a black box in that regard; no chance for you to intervene). 

 

So, instead of opening the database and trying to clean up the FileMaker code, open the database and run the Set Variable step to get the finished AppleScript code, i.e. let FileMaker do the work for you.

 

....did that make sense?

 

Not really …  :D

Posted

i came up with the idea to build an applescript conversion database.  you paste in the code, and poof, the calculated script spits out.  it works like a champ for the applescript to filemaker conversion.  now i'm working on the reverse so that if i need to take an calculated applescript back into applescript editor, it will drop all of the extra quotes and slashes.

 

I believe that if you paste your working AppleScript into a text field, then a calculation =

Quote ( NativeAppleScriptField )

will do the "poof, the calculated script spits out" part, and of course =

Evaluate ( CalculatedAppleScriptField )

will do the trip back.

Posted

wow....it's just that simple, isn't it.  hahaha.  i understand now.  thank you both very much.  i guess i was just making this much harder than it needed to be.

Posted

t's just that simple, isn't it. 

 

Yes, it is, but it is also - at least at this point - rather pointless, unless you find a way to inject your data into the calculated result. One way to do this:

 

Starting with native AppleScript:

tell application "Finder"
open file "MyFile.txt" of (path to desktop)
end tell

Quoting the above produces:

"tell application "Finder"¶open file "MyFile.txt" of (path to desktop)¶end tell"

Now we replace the literal filename with an easily indentifiable string, for example:

"tell application "Finder"¶open file "$myfilename" of (path to desktop)¶end tell"

So that the final calculated AppleScript can become:

Let ( 
script = "tell application "Finder"¶open file "$myfilename" of (path to desktop)¶end tell"
;
Substitute ( script ; "$myfilename" ; MyTable::Filename )
)
  • Like 1

This topic is 3820 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.