Returning Multiple Values From a Script

[SteveB]

Version 8 added the ability to return a value (script parameter) when a script exits. If the script is a top-level script, initiated by clicking a button, and the script is passed 3 fields as a script parameter, does anyone know how to return those 3 values into the passed fields?

Clearly, if the script were called by another script, the other script could decode the results. But what if its the only script? This situation comes up all the time for me, and my solution to it is clunky: pass the script a parameter that tells the script which of a dozen relationships the results apply to.

Steve

[Ender]

Sorry Steve, I don't think there's an easy method to dynamically set those target fields with the result of the script. The Exit Script[] function won't do it, and the other option is to use Set Field[] script steps at the end of the top-level script. The trouble then is knowing which fields the initial values came from. You might send the field names as script parameters instead of their values, then you can evaluate() the names to get the values. Then the only problem is having to use one of the dynamic Set Field[] tricks to return the results to the proper field (either a loop through all fields on a layout until the name matches, or a set of If[]-Else statements for each possible field.)

[Søren Dyhr]

I havn't yet found other areas for GetScriptResult( than to pass glolbal $$Values from one file to another, when everything take place inside one file.

Perhaps it could be good to see that task that comes ever so often - since you say:

This situation comes up all the time for me

One thing though comming to my mind is that recursive scripting stacks the paramters given in the call, this means that it's there again when the recursions unwind, this means that the real parameter to get in is:

http://www.filemaker.com/help/FunctionsRef-24.html

...while real values as such gets in via a Let( such as:

http://www.fmforums.com/forum/showpost.php?post/187787/

Two questions to be asked in each recursion, is if GetScriptValue( carries anything and if it's called with an empty script parameter.

But as I said, would a genuine task perhaps get my mind sorted. It's at present unclear to me, where such a demand belong to.

--sd

[SteveB]

Thanks, Ender. I didn't really think I could do it, since there is no way to script the left side of what goes into a SetField with a "variable". I got into it bacause of an article by Anton Anderson concerning script portabaility in the current issue of Filemaker Advisor...he implied that it could be done, but presented no examples. Maybe in versions 9 or 10.

Steve

[Ender]

Maybe you can ask Anton Anderson, and let us know how he does it.

[SteveB]

What he's probably talking about is returning multiple values through Exit Script, and decoding them in the calling script, but not passing the field values directly into the fields themselves.

Steve

[Søren Dyhr]

What he's probably talking about is returning multiple values through Exit Script

Yes, probably something getting dissolved via a Evaluate( like Janet Tokeruds http://tokerud.typepad.com/filemaker/2005/11/filemaker_8_usi.html

....just the opposite way!

--sd

[Oldfogey]

The requirement for a dynamic Set Field[], or equivalent, keeps coming up. There should be a special forum dedicated to this problem, where all the posts just disappear.

I suspect that the fundamental architecture is such that you cannot have dynamic target fields. A handy alternative in many cases would be a Case script step.

Are you listening FMI?

[comment]

From the beginning, FM made it simple by deciding that a reference to a field always means the value in the field. This is now getting problematic, as some functions do refer to the field's name (e.g. Get Repetition, or the trigger fields in Evaluate). I am not sure this is a fundamental architecture issue, but a major change in the reference convention will probably be required. Perhaps the dual syntax of GetField() is an indication of things to come - though one would hope a change of field's name would automatically propagate to its references.

A "Case script step" already exists: it's called Else If[].

[SteveB]

They've sort of taken a baby step in that direction, since we can now subscript a repetition field with a script variable. Although its impossible for us to solve, I'd bet they could do it without a lot of effort. Its the piece that's missing that makes a script truly portable. Pass the script fields that are surrounded by a start and end character like a "" that would tell the script to get the field values by location and return them by location. (Fortran happens to pass values by location using 2 foward slashes).

Steve

[Søren Dyhr]

Pass the script fields that are surrounded by a start and end character like a "" that would tell the script to get the field values by location and return them by location. (Fortran happens to pass values by location using 2 foward slashes).

One week do a secteric movement demand of filemaker to behave more OOD'ish http://www.fmforums.com/forum/showtopic.php?tid/175168/tp/1/ the next week is someone wishing for more procedural behaviours...

Gentlemen, this is a database tool not a programming language.

There are more urgent demands to apply to the metaphors dept. as raised in this:

http://network.datatude.net/viewtopic.php?t=107

...by and large does the rule look like: "The longer the scripts are to evolve the less structured does the data behave"

--sd

[SteveB]

Soren, the more I read your posts the less I understand what you're getting at. While I'm sure your English is far better than my Danish, if you try writing using very simple English, I'd appreciate it.

I'm not suggesting that Filemaker make anything that looks like Fortran (heaven forbid...the only thing worse would be to look like C++).

However, it's pretty clear (at least to me) that the problem I raised at the very beginning is a major impediment to creating truly modular scripts.

Steve

[Søren Dyhr]

OK! Should scripts be the carrier of data or should the record??

I'm not talking about what things should look like, but rather what "mission" each tool in the toolkit are designed to handle.

I see your word "truly modular" more as a rethoric thing than something which really can be substantiated. The issue I try to raise is this:

http://lala.essortment.com/objectparadigm_ruqg.htm

...but also this:

http://www.zend.com/zend/art/oo-proc.php

But David Kaschel put what I think in perspective when he in his Whitepaper for Novices" writes:

There are many cute and clever things that can be done in FileMaker that are workable, but not practical. They may tend to slow your solution considerably, or limit options down the road. Be very cautious when deciding to use specialized techniques in your solution. If they seem to require a lot of complicated coding, or manipulate FileMaker into doing something completely outside the database realm, you may be better off without them. If they add a slick feature to your database, but don’t really provide a significant functional advantage, pass them by. Think of these techniques as decorations on the tree. They can be wonderful and dazzling, but too many of them may bring down the whole tree.

--sd

[SteveB]

OK! Should scripts be the carrier of data or should the record??

Right now, under the circumstances I outlined at the beginning, the scripts carry the data. That's why there is a problem.

Steve

[Søren Dyhr]

Alright I'm having dificulties in visualizing the situation you here bring up:

This situation comes up all the time for me, and my solution to it is clunky: pass the script a parameter that tells the script which of a dozen relationships the results apply to.

How are the relations defined, what purpuse do they serve since this desire occures ...idealistic said shouldn't real data be moved around, and instead leaving it up to manipulation of keyvalues to get the required response. You're obviously no stanger to these principles, but perhaps it's your background, that makes you show a certain disregarding attitude to anything not being procedural in behaviour?

So if your question kind of ignores this principle, and you're keen to move real information by the scripts, are you talking about something drifting away from database realm.

--sd

Edited April 25, 2006 by Guest

[Søren Dyhr]

When reading (re-reading actually) this site:

http://edoshin.typepad.com/bits_and_pieces/2006/02/options.html

Did these words:

Then I found I have no use for them, at least for now, so they are postponed; only the simplest applications, such as passing parameters and maybe storing multiple values in a field or passing multiple values to a custom function are used.

I believe that they may be not necessary in v8 because of variables, but haven't yet established a workflow.

...remind me of this thread. This neat detail you wish to have included ...which I think defeats the object with databases as such, could perhaps better be accomplished by using another tool - take a look at all the optional programming environments availiable for this product, while keeping in mind that it indeed is cross platform'ish.

--sd