I'm finding myself using global variables more and more instead of
script parameters, especially when I want to use multiple parameters -
it just seems so much easier than packing and unpacking the script
parameters. But my question is, is this a problem? Are script
parameters more efficient?
Thanks for any advice,
Carla.
In article <1190371651.537723.322600@57g2000hsv.googlegroups.com>,
Carla
> I'm finding myself using global variables more and more instead of
> script parameters, especially when I want to use multiple parameters -
> it just seems so much easier than packing and unpacking the script
> parameters. But my question is, is this a problem? Are script
> parameters more efficient?
>
> Thanks for any advice,
>
> Carla.
Seems to me there are good reasons for using global fields, such as when
you want to provide for user entry of data.
However, global fields can make a solution more difficult to maintain,
as they clutter the field definitions and over time we may forget what
they are for.
Script parameters and script variables have a clear and limited purpose.
They do not clutter the field definitions, and make the solution easier
to maintain.
--
For email, change
Bill Collins
They each have their uses, and except for a single common functionality,
those uses are very different:
Both Script Parameters and global Script Variables can be used to pass
values from one script to another.
Parameters can provide a set of initial instructions such as how to
behave according to an existing condition as a button is clicked, but
they can't be changed while a script is running, which makes Variables
much more flexible in controlling a script.
I will sometimes run a script with Parameters and immediately assign
those values to Variables.
As for unpacking multiple parameters, perhaps this will simplify things
for you: I've seen various schemes to extract multiple parameters using
pipes or other characters as delimiters, but I have yet to see anything
so simple and elegant as a Custom Function (assuming you have the
capability) at http://www.BrianDunning.com (from the Tim Anderson Group):
GSP (num) =
Case (
num = 0 ; Get ( ScriptParameter ) ;
GetValue ( Get ( ScriptParameter ) ; num )
)
You define the parameters as a return-separated list of values using the
pilcrow:
"Red¶Yellow¶Orange"
so that GSP ( 1 ) returns "Red", GSP ( 2 ) returns "Yellow", etc.
GSP ( 0 ) returns the full list.
Matt
Free FileMaker Technique Demos: http://www.VirtualVermont.com/FMP
My Custom Functions:
http://www.briandunning.com/filemaker-custom-functions/resul ts.php?keyword=wills
On 9/21/07 6:47 AM, Carla wrote:
> I'm finding myself using global variables more and more instead of
> script parameters, especially when I want to use multiple parameters -
> it just seems so much easier than packing and unpacking the script
> parameters. But my question is, is this a problem? Are script
> parameters more efficient?
>
> Thanks for any advice,
>
> Carla.
>
Matt Wills wrote:
but I have yet to see anything
> so simple and elegant as a Custom Function (assuming you have the
> capability) at http://www.BrianDunning.com (from the Tim Anderson Group):
>
> GSP (num) =
>
> Case (
> num = 0 ; Get ( ScriptParameter ) ;
> GetValue ( Get ( ScriptParameter ) ; num )
> )
>
> You define the parameters as a return-separated list of values using the
> pilcrow:
>
> "Red¶Yellow¶Orange"
>
> so that GSP ( 1 ) returns "Red", GSP ( 2 ) returns "Yellow", etc.
>
> GSP ( 0 ) returns the full list.
>
> Matt
>
>
>
ah, then you haven't seen my custom function then:
Fn Name: GetSP_N
Parameter: N
Definition:
Let([
SP = Get ( ScriptParameter );
LIST = Substitute ( SP ; "|" ; "¶" )
];
GetValue( List ; N)
)
then in a script example:
SP = A|B|C|D|E
Set Field F_txt = SSP_N ( 2 )
returns B
This particular variant uses pipes as delimiters; and subs to a list, so
a script parameter might look like:
A|B|C|D|E
e.g. SP = print|operation|exOpForm
I use a 3 pack of what I refer to as 'control variables at the start of
virtually every script these days, it has become a very flexible way of
handling multiple conditionals sets in a script, I seem to currently
have a lot of user requests to do the same thing from several different
places...
new - Operation
#CONTROL VARIABLES
Set Variable [ $_FN; Value:SSP_N ( 1 ) ]
Set Variable [ $_WHAT; Value:SSP_N ( 2 ) ]
Set Variable [ $_FROM; Value:SSP_N ( 3) ]
If anyone is interested, I have an equally simple variant that allows
you to define the delimiter, in the custom calc as well like: GetSP_DLN
Set Field F_txt = SSP_DLN ( 1; "*" )
regards
Chris Brown
On Sep 21, 3:02 pm, Chris Brown
wrote:
> Matt Wills wrote:
>
> but I have yet to see anything
>
>
>
> > so simple and elegant as a Custom Function (assuming you have the
> > capability) athttp://www.BrianDunning.com(from the Tim Anderson Group):
>
> > GSP (num) =3D
>
> > Case (
> > num =3D 0 ; Get ( ScriptParameter ) ;
> > GetValue ( Get ( ScriptParameter ) ; num )
> > )
>
> > You define the parameters as a return-separated list of values using the
> > pilcrow:
>
> > "Red=B6Yellow=B6Orange"
>
> > so that GSP ( 1 ) returns "Red", GSP ( 2 ) returns "Yellow", etc.
>
> > GSP ( 0 ) returns the full list.
>
> > Matt
>
> ah, then you haven't seen my custom function then:
>
> Fn Name: GetSP_N
> Parameter: N
>
> Definition:
> Let([
> SP =3D Get ( ScriptParameter );
> LIST =3D Substitute ( SP ; "|" ; "=B6" )
> ];
> GetValue( List ; N)
> )
>
> then in a script example:
> SP =3D A|B|C|D|E
>
> Set Field F_txt =3D SSP_N ( 2 )
> returns B
>
> This particular variant uses pipes as delimiters; and subs to a list, so
> a script parameter might look like:
>
> A|B|C|D|E
>
> e.g. SP =3D print|operation|exOpForm
Wow. I'd missed the 'GetValue' function added in FM8, and always used
middlevalues, which was annoying because it had the trailing CR which
had to be cleaned off. So I've been running with a custom func that
does what GetValue does. I'll remove that bit of fluff, going
forwards.
I'm also curious why you use pipes as delimeters?
Lately I just use the List( ) function to assemble the parameter
lists. I can see that pipes are slighly more concise if you are
sending fixed parameter lists, but I find most parameters are fields
or variables, so you'd be assembling them bits of text using:
field::operation &"|" & relatedfield::something & "|" & $myvariable &
"|15"
which is ugly at best unless you've written a custom function to do
it, but then that is as much re-inventing the wheel as my own getValue
was, given list is built in as of 8.5.
At any rate, since you are ultimately operating on CRs anyway, why
bother with pipes at all?
cheers,
Dave
On 09/21/07 6:02 PM, Chris Brown wrote:
> Matt Wills wrote:
> > but I have yet to see anything
>> so simple and elegant as a Custom Function (assuming you have the
>> capability) at http://www.BrianDunning.com (from the Tim Anderson Group):
>>
>> GSP (num) =
>>
>> Case (
>> num = 0 ; Get ( ScriptParameter ) ;
>> GetValue ( Get ( ScriptParameter ) ; num )
>> )
>>
>> You define the parameters as a return-separated list of values using
>> the pilcrow:
>>
>> "Red¶Yellow¶Orange"
>>
>> so that GSP ( 1 ) returns "Red", GSP ( 2 ) returns "Yellow", etc.
>>
>> GSP ( 0 ) returns the full list.
>>
>> Matt
>>
>>
>>
>
>
> ah, then you haven't seen my custom function then:
>
>
> Fn Name: GetSP_N
> Parameter: N
>
> Definition:
> Let([
> SP = Get ( ScriptParameter );
> LIST = Substitute ( SP ; "|" ; "¶" )
> ];
> GetValue( List ; N)
> )
That's probably because you haven't posted it at BrianDunning.com.
One beauty of FileMaker is that there are so many different ways to do
something. The efficacy of a given method has to be measured in terms of
either speed hit or simplicity (what has come to be known as elegance).
There are several Script Parameter functions at Brian's site, some of
which are rather involved, compared to either yours or the one I
supplied. I had one myself, which I asked Brian to remove when I saw Tim's.
Between these two, though, there probably isn't a measurable speed
difference unless you're dealing with thousands of parameters, so how
does one say which is simpler, more elegant?
Yours uses Get ( ScriptParameter ), Substitute and GetValue within a Let
statement. Four functions, two variables, 80 non-space characters.
Reducing the variable to single letters ("S" instead of "SP", "L"
instead of "LIST"), that could be reduced to 70. Side question: Do 8.5
and 9 allow the use of "LIST" as a variable, given that it is a function
itself?
Tim Anderson's uses GetValue and Get ( ScriptParameter) within a Case
Statement. Three functions, one variable, 70 non-space characters,
reduceable to 66 by changing "num" to "n".
One function, four characters. Pretty close.
Matt
On Sep 22, 5:23 am, Matt Wills
> On 09/21/07 6:02 PM, Chris Brown wrote:
>
>
>
> > Matt Wills wrote:
> > > but I have yet to see anything
> >> so simple and elegant as a Custom Function (assuming you have the
> >> capability) athttp://www.BrianDunning.com(from the Tim Anderson Group):
>
> >> GSP (num) =3D
>
> >> Case (
> >> num =3D 0 ; Get ( ScriptParameter ) ;
> >> GetValue ( Get ( ScriptParameter ) ; num )
> >> )
>
> >> You define the parameters as a return-separated list of values using
> >> the pilcrow:
>
> >> "Red=B6Yellow=B6Orange"
>
> >> so that GSP ( 1 ) returns "Red", GSP ( 2 ) returns "Yellow", etc.
>
> >> GSP ( 0 ) returns the full list.
>
> >> Matt
>
> > ah, then you haven't seen my custom function then:
>
> > Fn Name: GetSP_N
> > Parameter: N
>
> > Definition:
> > Let([
> > SP =3D Get ( ScriptParameter );
> > LIST =3D Substitute ( SP ; "|" ; "=B6" )
> > ];
> > GetValue( List ; N)
> > )
>
> That's probably because you haven't posted it at BrianDunning.com.
>
> One beauty of FileMaker is that there are so many different ways to do
> something. The efficacy of a given method has to be measured in terms of
> either speed hit or simplicity (what has come to be known as elegance).
> There are several Script Parameter functions at Brian's site, some of
> which are rather involved, compared to either yours or the one I
> supplied. I had one myself, which I asked Brian to remove when I saw Tim'=
s
>
> Between these two, though, there probably isn't a measurable speed
> difference unless you're dealing with thousands of parameters, so how
> does one say which is simpler, more elegant?
>
> Yours uses Get ( ScriptParameter ), Substitute and GetValue within a Let
> statement. Four functions, two variables, 80 non-space characters.
> Reducing the variable to single letters ("S" instead of "SP", "L"
> instead of "LIST"), that could be reduced to 70. Side question: Do 8.5
> and 9 allow the use of "LIST" as a variable, given that it is a function
> itself?
>
> Tim Anderson's uses GetValue and Get ( ScriptParameter) within a Case
> Statement. Three functions, one variable, 70 non-space characters,
> reduceable to 66 by changing "num" to "n".
>
> One function, four characters. Pretty close.
Actually, assuming things are implemented optimally internally by
filemaker. Tim's is 2x as fast on large data.
As for character count, I wouldn't read much into that. Parsing in
filemaker **from what I can tell** is largely done when you create an
expression, not when you evaluate it. So function names, field names,
table names, etc are all likely pre-parsed into an evalutation tree
which then gets run when it needs to be evaluated.
The exceptions to this are $variable names and of course anything you
put inside an "evaluate()" function. These get parsed and evaluated at
run time. So using field:reallylongnamegoeshere vs field:x is
*identical*. But $variablereallylongnamehere vs $v is not. (However,
the difference between a 1 char variable and a 10 char variable is
generally irrelevant; though it might matter if you were lugging
around 1000 character variable names.
As for the actual functions (without getting into theory):
Case is fast.
Let is fast
Get(ScriptParameter) is fast
GetValue is slow
Substitute is slow
And actually, running the Substitute takes longer than anything else
by a considerable margin.
Of course, I agree, that you'd only ever *see* the difference in a
very long parameter list or a very high iteration loop.
-cheers,
Dave
Matt Wills wrote:
> On 09/21/07 6:02 PM, Chris Brown wrote:
>
>> Matt Wills wrote:
>> > but I have yet to see anything
>>> so simple and elegant as a Custom Function (assuming you have the
>>> capability) at http://www.BrianDunning.com (from the Tim Anderson
>>> Group):
>>>
>>> GSP (num) =
>>>
>>> Case (
>>> num = 0 ; Get ( ScriptParameter ) ;
>>> GetValue ( Get ( ScriptParameter ) ; num )
>>> )
>>>
>>> You define the parameters as a return-separated list of values using
>>> the pilcrow:
>>>
>>> "Red¶Yellow¶Orange"
>>>
>>> so that GSP ( 1 ) returns "Red", GSP ( 2 ) returns "Yellow", etc.
>>>
>>> GSP ( 0 ) returns the full list.
>>>
>>> Matt
>>>
>>>
>>>
>>
>>
>> ah, then you haven't seen my custom function then:
>>
>>
>> Fn Name: GetSP_N
>> Parameter: N
>>
>> Definition:
>> Let([
>> SP = Get ( ScriptParameter );
>> LIST = Substitute ( SP ; "|" ; "¶" )
>> ];
>> GetValue( List ; N)
>> )
>
> That's probably because you haven't posted it at BrianDunning.com.
>
> One beauty of FileMaker is that there are so many different ways to do
> something. The efficacy of a given method has to be measured in terms of
> either speed hit or simplicity (what has come to be known as elegance).
> There are several Script Parameter functions at Brian's site, some of
> which are rather involved, compared to either yours or the one I
> supplied. I had one myself, which I asked Brian to remove when I saw Tim's.
>
> Between these two, though, there probably isn't a measurable speed
> difference unless you're dealing with thousands of parameters, so how
> does one say which is simpler, more elegant?
>
> Yours uses Get ( ScriptParameter ), Substitute and GetValue within a Let
> statement. Four functions, two variables, 80 non-space characters.
> Reducing the variable to single letters ("S" instead of "SP", "L"
> instead of "LIST"), that could be reduced to 70. Side question: Do 8.5
> and 9 allow the use of "LIST" as a variable, given that it is a function
> itself?
>
> Tim Anderson's uses GetValue and Get ( ScriptParameter) within a Case
> Statement. Three functions, one variable, 70 non-space characters,
> reduceable to 66 by changing "num" to "n".
>
> One function, four characters. Pretty close.
>
> Matt
<<
> That's probably because you haven't posted it at BrianDunning.com.>>
nope, I haven't.
Mine is more useful to me as I can simply type the pipe in the script
parameter string, , and had even more useful to me not having seen the
Tim Anderson example previously :-) If I had I would have saved 20
minutes and been using Tim's probably. Whatever the keyboard shortcut is
for a pilcrow for "Red¶Yellow¶Orange", I would never remember (I assume
there is one), given that I couldn't even find it to test the
"Red¶Yellow¶Orange"...
Curiously using the "Red¶Yellow¶Orange" with my CF, it parses it
correctly without redefining the delimiter in the CF; a glitch or
advantage depending on perspective. An apparent anomaly none the less.
Another curiosity that one might not expect; I regularly find it useful
to monitor the SP's from DataViewer; the "Red¶Yellow¶Orange" displays as
Red Yellow Orange (losing the pilcrows), whereas "A|B|C|D|E" displays as
A|B|C|D|E.
As for custom function efficiencies in terms of character counts etc.
the parse is so simple and fast; speed differences are to me at least,
academic.
The Let I find almost universally good practice as I can adapt calcs
like this to other situations often simply by changing the input
definition; e.g. SP defined to something else. Not necessarily this
custom function, but Let syntax in general
LIST works in 8.5
regards
chris
d-42 wrote:
> On Sep 21, 3:02 pm, Chris Brown
> wrote:
>> Matt Wills wrote:
>>
>> but I have yet to see anything
>>
>>
>>
>>> so simple and elegant as a Custom Function (assuming you have the
>>> capability) athttp://www.BrianDunning.com(from the Tim Anderson Group):
>>> GSP (num) =
>>> Case (
>>> num = 0 ; Get ( ScriptParameter ) ;
>>> GetValue ( Get ( ScriptParameter ) ; num )
>>> )
>>> You define the parameters as a return-separated list of values using the
>>> pilcrow:
>>> "Red¶Yellow¶Orange"
>>> so that GSP ( 1 ) returns "Red", GSP ( 2 ) returns "Yellow", etc.
>>> GSP ( 0 ) returns the full list.
>>> Matt
>> ah, then you haven't seen my custom function then:
>>
>> Fn Name: GetSP_N
>> Parameter: N
>>
>> Definition:
>> Let([
>> SP = Get ( ScriptParameter );
>> LIST = Substitute ( SP ; "|" ; "¶" )
>> ];
>> GetValue( List ; N)
>> )
>>
>> then in a script example:
>> SP = A|B|C|D|E
>>
>> Set Field F_txt = SSP_N ( 2 )
>> returns B
>>
>> This particular variant uses pipes as delimiters; and subs to a list, so
>> a script parameter might look like:
>>
>> A|B|C|D|E
>>
>> e.g. SP = print|operation|exOpForm
>
> Wow. I'd missed the 'GetValue' function added in FM8, and always used
> middlevalues, which was annoying because it had the trailing CR which
> had to be cleaned off. So I've been running with a custom func that
> does what GetValue does. I'll remove that bit of fluff, going
> forwards.
>
> I'm also curious why you use pipes as delimeters?
> Lately I just use the List( ) function to assemble the parameter
> lists. I can see that pipes are slighly more concise if you are
> sending fixed parameter lists, but I find most parameters are fields
> or variables, so you'd be assembling them bits of text using:
>
> field::operation &"|" & relatedfield::something & "|" & $myvariable &
> "|15"
>
> which is ugly at best unless you've written a custom function to do
> it, but then that is as much re-inventing the wheel as my own getValue
> was, given list is built in as of 8.5.
>
> At any rate, since you are ultimately operating on CRs anyway, why
> bother with pipes at all?
>
> cheers,
> Dave
>
>
Hi Dave,
the majority of my SP's are fixed text strings rather than field values,
so pipes are a quick and easy type, and give better visual feedback, for
me, in Data Viewer. It also allows me to use spaces and parse separate
components containing separate words, which the pilcrow would do too,
but with the small complication in the Data Viewer mentioned below, so:
"A B|C|D" , data viewer as: A B|C|D, and parses >>
A B
C
D
As I also just noticed, the pilcrow doesn't display in DataViewer when
monitoring the SP (FM8.5Adv OS X.4.10). So
"Green Red¶Yellow¶Orange" displays in Data Viewer (SscriptParameter as:
Green Red Yellow Orange
Basically, it works for me.
regards
Chris
On Sep 21, 11:47 am, Carla
> I'm finding myself using global variables more and more instead of
> script parameters, especially when I want to use multiple parameters -
> it just seems so much easier than packing and unpacking the script
> parameters. But my question is, is this a problem? Are script
> parameters more efficient?
>
> Thanks for any advice,
>
> Carla.
Thanks, everyone, for the helpful responses and interesting
discussion. I think I need to experiment more with SPs - at the
moment, using GVs seems simpler to me, but it's probably a good idea
to embrace both!
Carla.
On Sep 24, 2:13 am, Carla
> On Sep 21, 11:47 am, Carla
>
> > I'm finding myself using global variables more and more instead of
> > script parameters, especially when I want to use multiple parameters -
> > it just seems so much easier than packing and unpacking the script
> > parameters. But my question is, is this a problem? Are script
> > parameters more efficient?
>
> > Thanks for any advice,
>
> > Carla.
>
> Thanks, everyone, for the helpful responses and interesting
> discussion. I think I need to experiment more with SPs - at the
> moment, using GVs seems simpler to me, but it's probably a good idea
> to embrace both!
>
> Carla.
The problem with GV's (in any language) is that they can be a royal
pain to manage, and its easy to screw up and inadvertantly overwrite a
value in a GV that the parent of the parent of a the current script is
using for something else. Is especially easy to do this during
maintenance 2 years later.
Script parameters / Exit parameters don't suffer from this.
Local variables are a godsend, but Global Variables we really could
have lived without. There's nothing we really need them for. Global
Fields already provide more functionality and fewer drawbacks.
The extra work to pack and unpack variables and script parameters is
worth it in the long run.
-dave
another advantage of Global Fields is being able to use them in
related files whereas a global $$variable is not _that_ global
another advantage of Global Fields is being able to use them in
related files whereas a global $$variable is not _that_ global
On Sep 26, 10:03 am, braeds...@googlemail.com wrote:
> another advantage of Global Fields is being able to use them in
> related files whereas a global $$variable is not _that_ global
Some other advantages:
They can be used on layouts to display data or collect data.
They can be used to drive relationships.
They are defined ('declared to exist') in a single well defined place;
so you know what globals fields are in use in the system,
With variables ... you don't. You pretty much have to inspect each
script to find out if it created a new $$global and then keep track of
it manually so you don't re-use a global name. This isn't an issue
with $script variables because they only exist within their own
script, but is a serious issue with $$global variables.
-cheers
Dave