Jump to content

PerfomScriptByName( scriptName ; parameters )


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

Recommended Posts

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

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

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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...

Link to post
Share on other sites

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.

Link to post
Share on other sites
  • 2 weeks later...

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)".

Link to post
Share on other sites
  • 4 years later...

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! ;)

Link to post
Share on other sites

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.

 

 

  • Like 1
Link to post
Share on other sites

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...

Link to post
Share on other sites

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

  • Like 1
Link to post
Share on other sites
  • 2 weeks later...

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 by Thomas Seidler
Link to post
Share on other sites

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