Jump to content

Define output path in script and edit text


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

Recommended Posts

I need help with two things.

First, I want a script that defines the output path for an exported text file. If possible, I want the user to select the output folder/location (example: MacHD:Users:User:Desktop:$filename.txt) on the first use of the script, and then the script will remember it each time the script runs. If the folder/location is missing, the script will ask the user to redefine it.

Second, this exported text file will be imported into Quark XPress 7.2. Currently, I'm using Tex-Edit to "massage" the data to remove quote marks, commas, add spaces, etc. Can Applescript edit text without the use of a text editor application? Can somebody provide a sample of the code? (Otherwise, the FM database becomes dependent on a working text editor application. If the FM database were to ever moves, the script would stop working.)

Thanks!

Link to comment
Share on other sites

First, yes, it could do this. First, since you want to store a path, you're going to have to have a place to store it within FileMaker. (Perhaps it could also be done with a "property:" in AppleScript, but likely not, or at least I don't know how.) Because the path will likely be different for every user, that means you need a "Users" table, with a record for each person. Which likely also means a log in Account for each user, so FileMaker knows who they are.

Then it's just a question of checking whether that particular location "exists" or not. If not, ask for a new one. In the later case I think it would be best to just ask for them to "choose folder", not file. You would supply the file name.

Alternatively you could decide where the folder/file should be, and create the folder if needed. Say within a FileMaker folder in their Documents folder. Or, even more politically correct :)-), within a FileMaker folder within the main Application Support folder, or within the user's Application Support folder (these are where, in my opinion, technical files supporting an application belong; there's a lot of folders in there already, from many applications).

AppleScript knows the paths:

path to application support

or

path to application support from user domain

set FM_support to (path to application support as Unicode text) & "FileMaker:"



tell application "Finder"

	if not (exists folder FM_support) then

		make folder at (path to application support) with properties {name:"FileMaker"}

	end if

end tell

As far as using AppleScript to massage the data, well, it could. But AppleScript itself does not have all the commands that an AppleScriptable text editor has; quite a few but not all, and not as easy to use. You could also use Unix command line inside AppleScript, using: do shell script "unix code" to run it. That is very powerful; but not exactly user friendly; very useful for extracting lines, fairly useful for Find/Replace, but touchy (to say the least).

Your worry that the AppleScript connection to the text editor will break if you move the FileMaker file is groundless. AppleScript addresses the application file via its name (actually via its application file id, which it resolves from the name when it compiles). So moving the FileMaker file does not matter. Neither does moving the text editor; unless it's not on the machine, in which case, yeah, it's broke :(-|

The "TextEdit" app is on all Macs. Or did you really mean "Tex-Edit Plus" (a highly AppleScriptable text editor). In either case it will work fine unless you delete the application.

Link to comment
Share on other sites

This topic is 6007 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.