Jump to content
Server Maintenance This Week. ×

DoScript problem with sending a script parameter


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

Recommended Posts

I am having trouble getting the 'scriptParameter' parameter of the DoScript command to work. Here is my calculation (set in the auto-enter options of a text field called 'gCatDisp1'):

gCatDisp1 =

Let(myscript = mFMb_DoScript( "TestScript"; Get ( FileName ) ;"john"); gCatDisp1)

The script "TestScript" triggers fine, but the Get(ScriptParameter) function returns nothing rather than "john". What am I doing wrong?

Also.. does anyone know if I have to pass the filename if I wish to also pass a script parameter? In other words, if you want to pass the second 'optional' parameter to the plugin does that require you to pass the first parameter?

BTW.. I'm using FM9 Adv on Mac OS 10.4.10

Thanks. John

Edited by Guest
Link to comment
Share on other sites

I am trying to use the free DoScript plugin to automatically trigger a script when a field value changes. The plugin command is executed from an auto-entry calculation that replaces existing value. Everything works fine except that I can not seem to get the optional 'scriptParameter' parameter of the 'mFMb_DoScript' command to work. You're supposed to be able to specify a script parameter that will be passed to the triggered script upon execution.

Here is my calculation which is set in the auto-enter options of a global text field called 'gCatDisp1':

gCatDisp1 =

Let(myscript = mFMb_DoScript( "TestScript"; Get ( FileName ) ;"john"); gCatDisp1)

The script "TestScript" triggers fine, but when I call the Get(ScriptParameter) function from within that script, I get "" rather than "john".

Anyone know what I'm doing wrong? Or is this broken?

FM9 Adv, Mac OS 10.4.10

Thanks. John

Link to comment
Share on other sites

Does the global field have anything in it? Is it really global?

Replace it with a literal string and see if it gets carried across.

The code snippet you posted makes no sense to me. The global field that is meant to hold the script parameter appears to have an auto-enter calc that sets a variable that triggers the script. So where does the value for the script parameter get set? No wonder it's returning null.

Link to comment
Share on other sites

The code snippet you posted makes no sense to me. The global field that is meant to hold the script parameter appears to have an auto-enter calc that sets a variable that triggers the script. So where does the value for the script parameter get set? No wonder it's returning null.

No.. the code is correct. The script param that I'm talking about is the value "john" in the code above. It is supposed to get passed to the script "TestScript" when it is triggered. I just got an email from Lieven Gekiere of FMButler confirming that my code is fine.

And.. I figured it out.. I have gotten bitten for the second time this month by the ridiculous, long-standing BUG in FM where it does not resolve filename references correctly. In other words, the whole problem here was that my FM database was named 'TexArt DB 1.0v11.fp7". As soon as I removed the first period from the filename, the code above works perfectly; the script parameter gets passed. When I add a period anywhere in the filename (that's not part of the extension), the parameter does not get passed. The script does fire, but no param gets passed.

This is EXTREMELY irritating as it is now the second time in a month that I have gotten bitten by this bug -- first with the 'ValueListItems' design function, and now with the DoScript plugin. And to further frustrate things, the work-around that works for the 'ValueListItems' problem does not work for DoScript. This is certainly not DoScript's problem, though. It is clearly a FM bug -- a long-standing one that should have been resolved years ago.

For those unfamiliar with the issue, normally when you call the 'ValueListItems' function, the syntax is something like this:

ValueListItems ( Get ( FileName ) ; "myListName" )

using the 'Get(FileName)' function so that you don't have to hard-code your filename (which the user should of course be allowed to change at anytime without breaking your system). This works fine as along as your filename does not contain a period. With a period in the filename, it fails.

The work around, in this case, is to add '& ".fp7"' to the Get function like this:

ValueListItems ( Get ( FileName ) & ".fp7" ; "myListName" )

and this works even if you have a period in the filename.

Now.. after 5 years (at least) of this bug existing, why is this not fixed?

And don't even get me started on the issue of whether or not a user should or shouldn't put periods in filenames. Of course you should be able to!! The user should be allowed to name a FM filemaker file any legal filename that the OS accepts. Both MacOS X, Win XP, and Win Vista allow for filenames in the Finder/Explorer that have periods in the names. And FM handles a period in the filename just fine in just about every other instance. But when activating a script command that requires the filename to be passed as a parameter, that is when it FM fails internally.

Very, very irritating. They must fix this!!

John

Link to comment
Share on other sites

"I have gotten bitten for the second time this month by the ridiculous, long-standing BUG in FM where it does not resolve filename references correctly."

It has NEVER been good practice to name FileMaker files like this. Never. Putting version info into the file name will mean that all other references to the file break when a new version is released.

It might be a bug, but it's not one that people who follow best practice encounter.

Link to comment
Share on other sites

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