PerformScriptByName( scriptName ; parameters ) [or PerformScriptById()]

.. Would be really useful just generally... particularly with things like dynamic interface elements, menu's etc.

It would HAVE to be by ID - since currently it is possible for two or more scripts to have the same name.

Edited December 5, 201015 yr by comment

Well I would agree... but they have gotolayout name by calculation (despite the possibility of duplicate names there).

Yeah, you have a point there...

Anyway, you CAN create a sub-script with multiple ElseIf[] and call it from the main script. More work to set up initially, but at least it won't break when script name is changed.

True, but you can't argue it would be useful.

On an unrelated note, why they let you have duplicate layout names or duplicate script names boggles my mind.

you can't argue it would be useful.

I am not. :

why they let you have duplicate layout names or duplicate script names boggles my mind

I guess it goes back to when Filemaker was (even) more Lego-like, and it didn't matter.

you CAN create a sub-script with multiple ElseIf[] and call it from the main script. More work to set up initially, but at least it won't break when script name is changed.

The multiple ElseIf is a bit laborious atm? But maybe only way. Could you just have one of the free script trigger plug-ins, and use that in a sub-script, using NameFromID ( id ; "script" ; _ ) or IDFromName ( name ; "script" ; _ ) - thus both by name or by ID could be handled by the same script, assuming you have a way of passing named parameters.

I'd call the script "Perform Script by Name [ ( scriptName | scriptID ) ; parameters ; control ].

Though I'm not sure they return the result? But maybe they do, so line would look thus:

set variable ( $result ; scriptTriggerCustomFunction ( scriptName ; parameters ; control ):

exit script ( $result )

mmmm...

Before SetFieldByName came into play, we could throw all the fields on a layout, loop through them all until we came to a target field and insert some text... And before script triggers came in to play we used plugins to emulate them.... and Before variables came along we used globals for everything.

The point is, while you can achieve PerformScriptByName in any number of ways, it's a clear omission from the new function sets which I can't see a reason for.

This would be an awesome addition to the next version, but the problem would be maintaining the names. Sometime name changes occur. So like comment said it should be by ID. Thus the need of a helper function called "GetScriptID (scriptName)".

Totally bump this, with Genx very much now...! My workaround has been tolerable under some situations, but not where one wants to do nice things like properly handle the dynamically run script's Get(ScriptResult), and it's failing or succeeding, being logged etc.

Then it's less than desirable. Far too much work to be running purely from Applescript which would be the only effective way forward (and only on Mac). I agree it's just a missing feature set and should work precisely as Genx indicates, same as GoToLayout (Layout/Script Name by calculation) where we all happily use the fixed IDs behind the layout to generate name and have our dynamic GoToLayout script steps.

Obviously, the other missing piece is GoToRelatedRecords by calculation for which one has no choice but cunning context and long ELIF statements which are a joke for dynamic scripting, but hey!

FM has progressed a lot since 2010; you can do this easily now with the fmp protocol:

http://www.filemaker.com/help/14/fmp/en/html/sharing_data.17.6.html

 

Obviously, the other missing piece is GoToRelatedRecords by calculation for which one has no choice but cunning context and long ELIF statements which are a joke for dynamic scripting, but hey!

And this one is easily done too: use ExecuteSQL() to gather the desired related IDs and drop them into a global text field.  use a generic relationship from that global to your destination; or just do a scripted find based on the gathered IDs.  If your layout naming scheme is consistent, then it can all be done very generically and dynamically without a bunch of ELSE IFs.  Obviously you'd use the Set Field by Name for the search requests.

 

 

FM has progressed a lot since 2010; you can do this easily now with the fmp protocol:

http://www.filemaker.com/help/14/fmp/en/html/sharing_data.17.6.html

That sir, is a fantastic piece of news and quite passed over in the official FM announcements and new feature list that I went through?! Thank you very much for pointing it out. This is quite brilliant, just tested and does exactly as required instantly calling within the orbit of standard FM scripting... very very impressive. Very looking forward to being in F14 (can't quite get there yet, cos just escaping simultaneous use of F5 which requires 10.6.8 max OS!  ).

And this one is easily done too: use ExecuteSQL() to gather the desired related IDs and drop them into a global text field.  use a generic relationship from that global to your destination; or just do a scripted find based on the gathered IDs.  If your layout naming scheme is consistent, then it can all be done very generically and dynamically without a bunch of ELSE IFs.  Obviously you'd use the Set Field by Name for the search requests.

At present work by a similar method, the hub method I guess, getting IDs, going to generic utility layout/relationship and to data I need. However, have found that while, as you state a scripted find is possible for true freedom, the speed (in F12 at least) of a scripted find of many (or even one!) UID is soooo much slower than GoToRelated functionality... so this is still not quite there, but will test in F14, as may well be faster, and then as you say, we're truly free from undynamic constraints...

Very looking forward to being in F14 (can't quite get there yet, cos just escaping simultaneous use of F5 which requires 10.6.8 max OS!  ).

 

Actually, the current fmp protocol has been possible since FM12...

It has gotten better over the years but at its core you could already make it run a script back to FM12.

See: http://www.filemaker.com/help/12/fmp/html/sharing_data.16.7.html

Here is a great reference on the FMP URL protocol

http://www.twdesigns.com/fmp_url_protocol/

Doh!@!! How COULD I have missed out on this all these years!!! That is *painful* (and mildly embarrassing! ), I've been using all manner of work arounds (AppleScript, Script Execute plug-ins to dynamically call, but both are a little less controlled than I'd like)!  Many many thanks for educating me @Wim Decorte and @Ocean West for the tip off to further details... T x

[mild rewind: having tried and tested looks as though I need 13.0v2 to do what i need: /$/?script on a file open locally...]

Edited September 21, 201510 yr by Thomas Seidler