Script variables totally rock. Every time I create or modify a script these days, I use script variables. You don’t seem to have to use a Commit Records command after you use the Set Variable script step. One less script step to enter.
I got lucky this week and was able to convince a customer with a large FileMaker 5.5 custom system I have developed over the years to convert to FileMaker 8. I was able to do the conversion starting Thursday and finishing to the 97% level by Sunday night. I spent 25 hours. I brought all the 17 files into a single file, improved and standardized the look, eliminated a lot of layouts in favor of tab controls and put in a few other cheap improvements that were easy in 8.
Besides my own FileMaker system for my business, this is the first fairly big all-FileMaker-8 solution that I’ve worked on. My client loves it. He often uses his database remotely, so likes the improvement in remote access speed. He likes the clairvoyance, the better look of the type (remember he is coming from FileMaker 5.5). He likes the new tabs. He likes the simplicity of the single file. Just today I made a few more improvements remotely. Very cool.
The reason we moved to 8 is that my customer wants to make some substantial improvements to his system. That’s the time to upgrade. When you’ll be able to immediately take advantage of all the new development tools, efficiencies and options available in the current version of FileMaker.
Now. About defining variables in script parameters. Remember that you can put a calculation into a script parameter. And you can use the Let function to define variables in that script parameter.
This is very cool, people. This is the syntax direct from a working example:
Let ( [$$_no_dialog = 0; $$_Report = “Tasks”; $$_Detail=“Itemized”;$$_Start=“Proposals”] ; “” )
Notice that the result calculation is just quotes around nothing. All this does is define script variables. This takes the place of either being limited to a single script parameter or creating a combo script parameter with pipes or some other divider between parameters and then having to parse it out later. This approach eliminates the need for parsing!!!
With this lovely script parameter. I tell multiple scripts what is happening. I want a print dialog, I want to go to the Tasks report layout, I want the itemized version of the tasks report not the summary version and I started this sequence in proposals, so even though you use multiple scripts, return me to proposals when you are done.
Here’s an excerpt from the reporting script:
Notice the last script step passes my button script parameter on to my generic preview and reporting script so that the variables for whether or not to show a print dialog ($$_no_dialog) and where (which layout) the button was pressed from ($$_Start) are available there.
I’m still learning to use standard naming conventions in naming my variables. And I’ve created a script called Clear Persistent Variables which I call from various scripts to clean up after myself.
I want to pass on thanks to the ones I know about who passed this trick on to me. Bob Harlow, a sharp and experienced FileMaker consultant in Marin county shared this trick with me. He said he got it from the inimitable Vincenzo Menanno of Waves in Motion fame and now working with Beezwax.
Technorati Tags: filemaker, FileMaker8
