Text based Script Editing

[rob s]

As much as I like the "ScriptMaker" interface, I was wondering is there any way to edit the scripts in filemaker with a text editor. It is easy to make sweeping changes when using a text based method. (e.g. Set Field on 10 fields when copying data from one table to another.)

[Neverland]

Great idea...sadly no way to do it.

SR

[rob s]

That is to bad, would it be possible to write a plugin that does it?

[bruceR]

All these notions about plugin capabilities seem to not recognize the basic nature of plugin technology. It is essentially just a calculated field. You pass something to an external, and it returns a result and if you want, you put this value in a field. It doesn't do anything else.

The external might to any number of things - present a dialog, whatever - but it just returns a result. You're not going to modify scripts or layouts or anything else basic to Filemaker structure with a plugin.

Of course it would be easy - and has been easy for years - to do what you're talking about with applescript. You can place the values in text fields or whatever.

[BrentHedden]

Troi automatisering used to create a plugin just for that purpose. It's called ProMaker. Unfortunately, they stopped developing it, but offer it as shareware now. They say it works with FileMaker 3 & 4, but says nothing about later versions, so I would suggest just give it a try with Version 7. According to Troi's website, it only available for Mac. Hey - give it a try, and if it works, great. If not, then you only spent a small amount of time trying.

http://www.troi.com/software/promaker.html

[bruceR]

Nope, that is not what the plugin did. The most any plugin can do inside Filemaker is put a value in a field. However, the actions it can take include actual manipulation of the interface to robotically build standard scripts and field definitions. Your text can drive the robot. That's completely completely different from having actual text-based dynamic scripts, and the only way to do that is with applescript.

[rob s]

Are you saying that it would be possible to make an Apple Script parser that took in a script as text input, converted it to a filemaker script, and then entered it into the scriptmaker. It sounds like a hack, (and a whole lot of work), but that would get the job done.

In my current database I move data in and out of a lot of global fields all of the time, and each time I want to move it to a different source/destination, I have to spend like 15/20 minutes manually changing each field with the GUI and verifying the changes. In a text script, this is a simple find and replace.

[bruceR]

"Are you saying that it would be possible to make an Apple Script parser that took in a script as text input"

No. Though actually I did that once long ago.

I'm saying that if you change the scripts to Perform Applescript [YourField] then you can edit the text of YourField and be done with it. Applescript is excellent for creating dynamic get field and setfield statements.

[rob s]

The problem I will run into with AppleScript is I want the database to be portable to a Windows box. If I just use the apple script to enter the script, then I can do the development on a mac, but the database will still run on a PC. For the time being, I might just have to go with the "Perform Applescript" solution because I have a 70 field table that I am trying to avoid.

[bruceR]

Can you describe more about what you are trying to do?

You could also do XML based import/export, that allows you to dynamically match fields. Yet another thing to do - though it sounds like it may not work have a fixed set field action but using a variable source. Are all the targets fixed but you want differnt source fields? Sounds like it is no from what you said previously but I thought I'd ask.

So you would always set field (CustomerName, gText1). But you might set field gText1, getfield("gSourceField") beforehand, and whatever field name you enter into gSourceField will be used.

[rob s]

I have a few databases that are all accessed through a master database. The master database only contains global fields that are used to view/modify/add new records to the other databases. (This way, the user never has direct write access to the sub databases) When the user views/modifys a record, the script copies all of the data from the selected record from the sub database, into the global fields. When the user saves the changes, a script copies all of the data from the global fields back to the database. I have seen this structure in a few posts, but I can't find an elegant solution to transfer all of the data between the sub-database and the global fields.

I asked the initial question because, as a coder by nature (gui programming is relatively foreign to me), i think the ability to enter text scripts would be very efficient.

[bruceR]

With applescript you wouldn't have to enter any field values at all, ever, if you set thing up right. No need for text editing.

To applescript, a record is kind of like a spreadsheet, and you can read/write all the values in one shot. If the field order is the same in both layouts (your global layout and data layout)

See attached. Requires a Mac.

WriteGlobals.zip

[rob s]

"If the field order is the same in both layouts (your global layout and data layout)"

Thanks a bunch, that was really helpful. Unfortunately in this case, the fields are all over the place.

A possible solution, make two dummy layouts for transferring data. One for the source fields and one for the destination fields. This way it doesn't matter what the layout is one the form the user is actually using.

Testing it now.

---

I tested this out and it works great, a nice thing, is now I only need one script to transfer data in and out of tables.

-- Get the source and destination layout

set sourceLayout to cell "ReadDataSourceLayout" of table