Thomas Seidler

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

Mask is great logical thinking! Comment is impressive! And gracious in giving his thinking to UK FMers! I've uploaded a custom function to do a few more of the Wikipedia validation information trix too... http://www.briandunning.com/cf/1813

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

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!

i realise i have an unusual approach to ScriptTriggering that's probably not helping things. For various reasons I tend to use zippScript etc, to fire off Scripts from calculation boxes rather than by actually directly calling them, it allows me more script modularity etc, but comes perhaps at a price of clarity and control...

No, you'd not need to hard code, the Get(ScriptStack) would return the call object if known, i.e. button or Script Trigger (i.e. all the info available to Script Debugger), so you'd just have a custom function to rip the Script Trigger scripts (or what have you) from the stack, and hey presto, i know if there are other scripts running (above and beyond Script Triggers) without any further ado. That said, in the meantime I'm all for solid variable solutions, can you post a link to your preferred one as a solution to this problem? You'd write custom functions on the back of it that would tell us things like: CF(ScriptStack; "ScriptTriggers") and return a value separated list of which ones are in stack. If my script GoesToLayout and hits the start of a table triggering OnRecordLoad, and then GoesToLast Record, now I only want it to run the last instance of OnRecordLoad... but not twice. So I can check to see if another instance of OnRecordLoad script trigger exist, and just run the last one... etc?

Ah, yes, I didn't mention, I realise I could also really use source of Script if known, as per Script Debugger: e.g. Button/OnKeyStroke etc - the primary area (as I recall) where I have found myself wishing I could check the stack was from ScriptTriggers... So if you had an OnRecordLoad or OnLayoutEnter script you didn't want to run if any scripts were running, that any script would by default have last word... so within the Script Trigger: If ( ValueCount ( CustomFunction_ScriptStackHandler ( Get(ScriptStack) ; "RemoveSomeScriptTriggers" ) ) ): Exit Script // override default behaviour controlled by Script Triggers Else: Continue with Script Trigger Of course variables can be set, and I'm aware many do have pretty thorough systems for them, and the $$ScriptTriggersOff approach, but it's a little trixxy don't you think? I like your script trigger demo with Mislav Kos. Do you have a preferred approach for controlling ScriptTrigger behaviour simply?

Once again, 5 years on, I find myself wanting this available still...!!! It could have the identical format to delivered data in Script Debugger: Script Name ( File Name.fmpXX { , Parameter: *quoted parameters* } ). We could happily parse it up, just to have that list available. I've realised logically it is impossible to do accurately via the $$CallStack approach, which is also exceedingly laborious: every script entrance but add to stack, and before every exit/halt the stack must be exited. I was thinking (and in my latest feature req submission stated) that Pause/User abort is the doom of such scripts. And I think it probably is, but if you turned user abort off period, you could remove from stack before Pause and add to stack after pause, but that's still not quite going to be right (as far as I can think, cos if a new script comes in and resumes old scripts etc., the stack won't be quite right all the time). Mmm... does no one else want this single function?

Sorry to be thick Kris M, but can I clarify your comment: "building functionality with 14 that does not exist in 13"... I too had this question, we are just about considering moving to a new server, and wanted to go stable, so FMS13v10 looks very tempting from that point of view. But I do want the F14 functionality, however, are you saying that the server won't support that at all? I can understand it wouldn't support new functions that we might use in the field definitions on the back end etc, but since it is effectively headless surely ScriptMaster, layout features or new ScriptTriggers shouldn't bother it [am i mis-remembering that script-triggers do not work on Server, i can't seem to find the documentation!]? And we should therefore be able to use the non-data/backend 14 functionality, since it's just stored within the planned .fmp12 functionality? http://help.filemaker.com/app/answers/detail/a_id/15003/~/filemaker-server-14-host-and-client-compatibility-chart ...is not particularly helpful in this aspect. Johhhn, what did you find to be the case?

OK, dead topic, but I'm grateful to @HazMatt for the idea of such a script, and Merlyn. Been facing ongoing same problems and it's dead handy. Another Applescript alternative if you don't mind the administrator password being in plain text in FileMaker: do shell script "sudo ntpd -g -q" user name "Administrator User Name" password "------" with administrator privileges

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

Scuse late posting, but really peeps shouldn't think Filemaker on a Mac doesn't have HTML email capacity, we've been enjoying it (with help of Applescript & XMail) since 2005ish. http://fmforums.com/forum/showtopic.php?tid/217843/ possible on Mac OS X for free, utilizes XMail osax. Very effective. Been using for years, but only now bothered to start contributing to community, and indirectly i'm hoping some of you will donate to JB LeStang, to encourage freeware/donationware developers. V reliable... + automatable attachments etc. I hope my demo is clear enough to follow!

Am I being stupid? I reckon I must be! : And someone bright here will tell me so and why! (as usual!) They surely wouldn't have gone to the trouble of installing script triggers as just script triggers, when they could have just grabbed the 'Button Setup' model to enable triggering of script steps directly - for when we want to script trigger simple things. What are the reasons for not doing this? If they change it, one HUGE obvious caveat would be to ensure all old script triggers do not get broken. So they default to a 'perform script [resume]' and use previous script target and same parameters. I wouldn't dream of rewriting my code to adapt to such a change (as has happened in past with other things like GoToLayout I think, certainly one of them in the change from 6 to 7).

Name: Sort Records by Calculation Type: Script Step Parameters: fieldNameList [ValueList], sortOrderList [ValueList] These are both set by specify calculation dialog boxes. It is the users responsibility to make sure they balance - otherwise script step returns error ("invalid parameters" or some such). fieldNameList is a valueList of field names. sortOrderList is a valueList containing: ascending, descending OR 'valueList' for custom order. Behaviour: if ( ValueCount ( fieldNameList ) ≠ ValueCount ( sortOrderList ) ) then ERROR "invalid parameters" (as above) Perform sort with field order given in list, using sortOrder to determine individual field sort order. Example usage: Sort Records by Calculation ( "MonthsOverdue¶DueAmount" ; "Descending¶Descending" ) Workaround [Mac only]: Put it in a script wrapper with those two parameters. Have sort fields present on layout to enable use of following code within PerformAppleScript: "sort by { field "" & Substitute( $fieldnameValueList ; "¶" ; "", field "" ) & "" } in order { " & Substitute ( $sortorderValueList ; "¶" ; ", " ) & " }"

[color:red]Mac Only solution - uses applescript & open source osax to enable full featured email within FileMaker. Ingredients: XMail 3.7 osax, Applescript, FileMaker (with custom functions: 1 for XMail & 2 extra dictionary/named parameter functions - u could easily switch with your own) I see others still battling with similar issues. This solution allows HTML (and easy multiple attachments though I see a good post covering one dynamic attachment). Been upgrading my in house solution, and had to make it simple to implement for F11. So if anyone else wishes to benefit from the code, do so. I'm using Jean-Baptiste Le Stang's XMail Osax. Couldn't post in the custom function sites because of dependencies - and dependent functions are not mine to upload (SFR first wrote the dictionary functions). Explanatory article & demo file. [color:red]Mac Only (cos of applescript usage). Now if someone could do the equivalent on a PC (is it possible) we could merge them together and have an open source complete solution! Though I guess F12 will fix that. Enjoy, Tom