Hi,

I am looking to use script parameters to avoid having to duplicate scripts with only minor changes. I have a global variable of $$OutputMode and this is a "V" when report is to be viewed on the screen and "P" when it's to be printed. I have an If statement in the script that runs depending if its V or P. Problem is that I don't know how to set this variable when entering the script.

Some information I have points to using the script parameter of (for example)

$$OutputMode="V"

but the variable monitor (in 8.5 Adv) shows that the variable doesnt change when passing into the script.

How do I change a global variable in a script parameter.

Thanks,

Greg

Lol Greg, I so have NO CLUE what you're asking, but see if this small demo on scriptParameter's helps.

Cheers.

scriptparameters.zip

How do I change a global variable in a script parameter.

Well by writing a calc including a Let( statement in the paramter def. But I do fully follow Genx scepticism here, how many scripts are going to use this variable ...it seems like just one, where nesting in conditions based on a hardwired paramter usually does the trick.

Another way is to ignore the script paramters what so ever and instead make following unstored calc'field:

Case (Get ( LayoutNumber )-1;Let($$aVar="P";"");Let($$aVar="V";""))

or

Let($$aVar=Case (Get ( LayoutNumber )-1;"P";"V");"")

...and put it on the two layouts (with a text colour identical with the background), where the same script needs to behave differently!

--sd

Set Variable [$$outputMode; Get(ScriptParameter)]

I would use a single $ variable, unless you're calling subscripts.

When defining the button that the script is to run, you put a V or a P in the "optional script parameter" box.

.. Seriously, is no one listening to my question of logically why?

Unless Greg wants to either View the reports or print them for the duration of the session and the idea of the script is to toggle that, there is no point in using a variable... let alone a global one.

Especially if all you're doing is taking a script parameter, converting it to a variable and then doing the test on the variable (which equals the script parameter) instead of just doing the test directly on the script parameter.

E.g.

Set Variable[$var ; Get(ScriptParameter)]

If[ $var = "V" ]

Do this

Else If[ $var = "P" ]

Do This

End If

Sigh, anyway, good night to all and so on and so forth.

I disagree there is no point in setting variables from Script Parameters. First, it makes the code cleaner and robust, also, if you need to reference the parameter more than once, then it eliminates a function call get(scriptParameter), also, you may at some point need to pass more than one parameter into the script, which would then require a complete rewrite of the script.

Seriously, is no one listening to my question of logically why? Sigh, anyway, good night to all and so on and so forth.

Good morning here!

I'm not sure where you put that question in your original post, but I use variables in places where they are seemingly unnecessary because they allow me to "chunk" the code which I think makes it easier to read. Defining the variables up front also makes it simpler if I ever need to update or change that part of a script.

In this case, they may be truly unnecessary, but I also don't know what else he's got going on in his script, so why not err on the side of caution?

And that's all I'm going to say about it, as last time I advocated adding *parens* that weren't strictly necessary on this forum, I didn't really enjoy the experience.

Edited June 28, 200718 yr by Guest

it eliminates a function call get(scriptParameter)

I am not convinced calling Get (ScriptParameter) is that much different from calling $$someVariable.

This is a good point, I'm not conviced either, but I've always been taught to minimize function calls...for better or worse.

If for no other reason:

$v

is less typing than get(scriptParameter)

I've always been taught to minimize function calls...for better or worse.

I've been taught to question the reasons, rather than follow blindly. I *am* convinced, though, that transferring data from one register (script parameter) to another (variable) does take time and consumes power.

less typing

That's no reason. Look, I have nothing against people doing whatever they find convenient, but we are talking about what's recommended practice - or at least I think we should be.

These are well documented best practices in every object oriented language I've ever used inlcuding Java and C++ and VB. So, yes, I am "following blindly" the best practices of much more advanced languages.

My grandmother used to cool her tea that way - pouring it from one cup to another. But I doubt she would be considered an advanced object-oriented language.

What a stir I have caused. Im thinking that I didnt explain my scenario well.

The script that I wish to run has an IF statement in it, and depending on the V or P variable evaluated at that point (current setup anyway), the script will print or view a report.

Perhaps I dont need a variable, but I do wish to somehow parse info the script to advise whether or not to print or view it with the If statement.

The script is run from the same layout, just from a different button on the layout so checking for the layout from which it is invoked may not work.

When using a variable, I seem to be stuck in setting the variable value in the functions area (cant see how its done) - as opposed to a script where I know the syntax to set a variable. My option was to run a script whose first line set the variable value, then the second line jumped to the main report script, but thought there must be a way to set the variable without the extra step. If not, thats cool.

Thanks for the discussion peoples.

Greg

My grandmother used to cool her tea that way - pouring it from one cup to another. But I doubt she would be considered an advanced object-oriented language.

LOL!

Greg, take a look at the example post above, it shows you how to actually pass the script parameters into the script.

By experience, specially on database accessed remotely, there is a performance issue that is not documented anywhere.

Go To Layout [ by name by calculation ; Get ( ScriptParameter ) ]

or

Set Variable [ $_myTargetLayout ; Get ( ScriptParameter ) ]

Go To Layout [ by name by calculation ; $_myTargetLayout ]

in favor of the second code

And I mean the longest code evaluates quicker !

HTH

Edited June 29, 200718 yr by Guest
well, not sure it's clear enough...

I suppose it has something to do with the fact that the parameter would have to be requested from the server each and every time where as the variable would be localized straight off?

Yes, that's my deduction too.

Which gives credit to the techniques where each parameter becomes a variable when the script is called, without the need of the Set Variable script step.

Edited June 29, 200718 yr by Guest

Mmmm, fair enough i always use variables for this any way because i practically never pass just one parameter to a script and have to parse them out.

The primary reason I posted my first statement is that Greg doesn't seem to know how to get the parameter into the script in the first place - hence why I was trying to move the discussion away from variables. This seems to back up my assumption:

When using a variable, I seem to be stuck in setting the variable value in the functions area (cant see how its done) - as opposed to a script where I know the syntax to set a variable.

Anyway, interesting pick up of info.

Don't think I've thanked you for learning anything before Ugo.

Thanks Lol.

Cheers.

The primary reason I posted my first statement is that Greg doesn't seem to know how to get the parameter into the script in the first place - hence why I was trying to move the discussion away from variables.

Sure.

Actually, I was commenting on the discussion that followed and on Roy and Michael's soups - or was it tea -

Scripts are only run locally, never by the server, so there must be some other reason for the performance difference in Ugo's example.

The server runs calculations for finds on unstored fields, record access permissions calcs, and maybe validation calcs. I think that's about it, and all the other calculation's are done by the client.

It's true that requesting certain Get() functions and variables from the server will be very slow, but I don't see how that can be what's happening here.

Hi Shawn,

I can replicate this in any of my solutions, specially again when accessed remotely, whatever the platform and computer, whatever the connexion speed.

I had to turn the previous scripting process to this new structure in order to increase performance on these hosted databases.

Can we deduct at least than evaluating a variable is quicker than evaluation a Get ( ). Then we'd partially have an answer.

If you don't know, then I don't :P

Edited June 29, 200718 yr by Guest

I would expect variables to be faster than most Get()'s, but my understanding of your example was that you are still doing the Get(ScriptParameter), but storing it off in a variable first makes it faster.

That seems nonsensical, and I would imagine it must be some subtle bug in the calc-engine or Go To Layout script step that is causing the large slow-down.

Or are you instead saying you do the Get(ScriptParameter) only once, store it, and repeatedly use it within the same script?

Can we deduct at least than evaluating a variable is quicker than evaluation a Get ( ).

A quick test shows that evaluating a $variable is about 7% quicker than calling Get (ScriptParameter). However, you need to take into account the time it takes to translate the script parameter into a variable.

To put it another way:

If you are calling the parameter 15 times or less, the translation is actually slowing you down.

Or, to put the whole thing in perspective:

On my relatively slow machine, you can save a whole second - if your script calls the data 40,000 times.

I agree with Shawn: you should test the Go to Layout[] issue in isolation.

I would expect variables to be faster than most Get()'s, but my understanding of your example was that you are still doing the Get(ScriptParameter), but storing it off in a variable first makes it faster.

That seems nonsensical, and I would imagine it must be some subtle bug in the calc-engine or Go To Layout script step that is causing the large slow-down.

Or are you instead saying you do the Get(ScriptParameter) only once, store it, and repeatedly use it within the same script?

Nope, just the way I said it.

Involving a $variable is quicker than evaluating a Get ( ScriptParameter ) into the Go To Layout script step. And as you point, it's nonsensical in the fact that I am declaring the $variable ( thus involving an evaluation of the Get ( ScriptParameter ) previously.

So the problem seems not to be the evaluation itself but the 'context' in which it is evaluated. At present, anywhere a 'by calculation' is involved - Go To Record, Go To Layout, Go To Portal Row -, I first declare the variable then re-use it.

It may be only an issue with the Go To Layout script step. Thanks for having tested that for us, Michael. I don't know about the 7%, what I can see that with a remote access, the difference is enormous ( but depends also on what is on the targeted layout and the connexion speed ). Targetting a 'standard' layout takes 1 second with the outlined method and can take up to 3/4 seconds with the sole Get ( ScriptParameter )

Edited June 29, 200718 yr by Guest

My test involved repeatedly setting a field with (a) Get (ScriptParameter) or ( $variable.

In view of what you said, I have changed the test. In an attempt to eliminate any 'bias' the Set Field [] step may exhibit towards one or another, I have used these looped steps:

(a)

Set Field [ Table::Value; [color:blue]Let ( x = Get ( ScriptParameter ) ; x ) ]

(:

Set Field [ Table::Value; [color:blue]Let ( x = $parameter ; x ) ]

And curiously enough, [color:red]now the results are identical!