What is my Script Parameter?

[MoonShadow]

1) Is there a way to determine what is currently 'stored' as my script parameter? All I can think of is to set a global field with it and look. It doesn't seem to work in a calculation (doesn't update as the script runs) even as unstored.

2) Is it true the parameter will not pass to another script without starting the sub-script with Get(ScriptParameter) again?

3) Is it true that Script Parameters will behavior in this same fashion if passed between files?

Situation: I'm using them a lot and I need to troubleshoot some problems with them.

Thank you.

Item 1 is a bit unclear ... can I test what is being held on a Script Parameter within a script, ie, If[ IsEmpty(Get(ScriptParameter)) ] or do I need to set a field and test the field?

[MoonShadow]

1) Is there a way to determine what is currently 'stored' as my script parameter? All I can think of is to set a global field with it and look. It doesn't seem to work in a calculation (doesn't update as the script runs) even as unstored.

2) Is it true the parameter will not pass to another script without starting the sub-script with Get(ScriptParameter) again?

3) Is it true that Script Parameters will behavior in this same fashion if passed between files?

Situation: I'm using them a lot and I need to troubleshoot some problems with them.

Thank you.

Item 1 is a bit unclear ... can I test what is being held on a Script Parameter within a script, ie, If[ IsEmpty(Get(ScriptParameter)) ] or do I need to set a field and test the field?

[MoonShadow]

1) Is there a way to determine what is currently 'stored' as my script parameter? All I can think of is to set a global field with it and look. It doesn't seem to work in a calculation (doesn't update as the script runs) even as unstored.

2) Is it true the parameter will not pass to another script without starting the sub-script with Get(ScriptParameter) again?

3) Is it true that Script Parameters will behavior in this same fashion if passed between files?

Situation: I'm using them a lot and I need to troubleshoot some problems with them.

Thank you.

Item 1 is a bit unclear ... can I test what is being held on a Script Parameter within a script, ie, If[ IsEmpty(Get(ScriptParameter)) ] or do I need to set a field and test the field?

[Ender]

Hi MoonShadow.

1. With Developer, you can see the script parameter while using the script debugger.

2. Yes, if you need to propagate your initial script parameter to a sub-script, you must do so explicitly. I just use get(scriptparameter) as the parameter to the sub-script.

3. Yes, script parameters behave the same in multiple files as in one file.

If your script parameters are in a long text string, you may need to set a global at the start of each script you're debugging in order to see everything. The script debugger doesn't show much.

[Ender]

Hi MoonShadow.

1. With Developer, you can see the script parameter while using the script debugger.

2. Yes, if you need to propagate your initial script parameter to a sub-script, you must do so explicitly. I just use get(scriptparameter) as the parameter to the sub-script.

3. Yes, script parameters behave the same in multiple files as in one file.

If your script parameters are in a long text string, you may need to set a global at the start of each script you're debugging in order to see everything. The script debugger doesn't show much.

[Ender]

Hi MoonShadow.

1. With Developer, you can see the script parameter while using the script debugger.

2. Yes, if you need to propagate your initial script parameter to a sub-script, you must do so explicitly. I just use get(scriptparameter) as the parameter to the sub-script.

3. Yes, script parameters behave the same in multiple files as in one file.

If your script parameters are in a long text string, you may need to set a global at the start of each script you're debugging in order to see everything. The script debugger doesn't show much.

[MoonShadow]

Hi Mike,

"The script debugger doesn't show much. " Exactly. Okay, I was hoping I could force a calc to display the entire contents so I wouldn't have to add Set Field lines in my scripts while testing. I might have gotten carried away in script parameter use, I'm afraid.

Using the script parameter as the script parameter. I like that!! Clear thinking about their use may help me solve the problems then. Thanks.

[MoonShadow]

Hi Mike,

"The script debugger doesn't show much. " Exactly. Okay, I was hoping I could force a calc to display the entire contents so I wouldn't have to add Set Field lines in my scripts while testing. I might have gotten carried away in script parameter use, I'm afraid.

Using the script parameter as the script parameter. I like that!! Clear thinking about their use may help me solve the problems then. Thanks.

[MoonShadow]

Hi Mike,

"The script debugger doesn't show much. " Exactly. Okay, I was hoping I could force a calc to display the entire contents so I wouldn't have to add Set Field lines in my scripts while testing. I might have gotten carried away in script parameter use, I'm afraid.

Using the script parameter as the script parameter. I like that!! Clear thinking about their use may help me solve the problems then. Thanks.

[MoonShadow]

Mike, the final part I forgot ...

Can I test within a script whether the Script Paramater is empty - as part of a regular script, I mean? So the script can respond differently if it is empty?

[MoonShadow]

Mike, the final part I forgot ...

Can I test within a script whether the Script Paramater is empty - as part of a regular script, I mean? So the script can respond differently if it is empty?

[MoonShadow]

Mike, the final part I forgot ...

Can I test within a script whether the Script Paramater is empty - as part of a regular script, I mean? So the script can respond differently if it is empty?

[Rob 7 Collins]

for #1:

Make sure if you are setting a value in a field you commit that value with the

Commit script step!

IsValid(field) will tell you if the type of data is appropriate to the type of

value in the field. Like, "hello world" is appropriate for a text field, but it

isn't valid in a "date" field. ...You'd need a global table with a field for

each seperate base type to always be able to know what type it is (actually,

less if you want to work the logic).

Show Dialog Box [ Get ( ScriptParameter )] will show YOU the actual data in the

script parameter, while a calculation's If, Case, etc, conditionals

tell your script if that data looks like what you expect. For example, I want

to open a layout at some point in the script if the parameter says to (like,

"open"), but to perform a search in the current layout on a date passed to the

script if the parameter is a date. Even though a date is passed by one script,

while a date or the "open" text is passed by another, I never pass anything else

to the script, so my condition in my script is "If [ Exact ( Get (

ScriptParameter ) ; "open"] " ... "Else #date stuff goes here".

[Rob 7 Collins]

for #1:

Make sure if you are setting a value in a field you commit that value with the

Commit script step!

IsValid(field) will tell you if the type of data is appropriate to the type of

value in the field. Like, "hello world" is appropriate for a text field, but it

isn't valid in a "date" field. ...You'd need a global table with a field for

each seperate base type to always be able to know what type it is (actually,

less if you want to work the logic).

Show Dialog Box [ Get ( ScriptParameter )] will show YOU the actual data in the

script parameter, while a calculation's If, Case, etc, conditionals

tell your script if that data looks like what you expect. For example, I want

to open a layout at some point in the script if the parameter says to (like,

"open"), but to perform a search in the current layout on a date passed to the

script if the parameter is a date. Even though a date is passed by one script,

while a date or the "open" text is passed by another, I never pass anything else

to the script, so my condition in my script is "If [ Exact ( Get (

ScriptParameter ) ; "open"] " ... "Else #date stuff goes here".

[Rob 7 Collins]

for #1:

Make sure if you are setting a value in a field you commit that value with the

Commit script step!

IsValid(field) will tell you if the type of data is appropriate to the type of

value in the field. Like, "hello world" is appropriate for a text field, but it

isn't valid in a "date" field. ...You'd need a global table with a field for

each seperate base type to always be able to know what type it is (actually,

less if you want to work the logic).

Show Dialog Box [ Get ( ScriptParameter )] will show YOU the actual data in the

script parameter, while a calculation's If, Case, etc, conditionals

tell your script if that data looks like what you expect. For example, I want

to open a layout at some point in the script if the parameter says to (like,

"open"), but to perform a search in the current layout on a date passed to the

script if the parameter is a date. Even though a date is passed by one script,

while a date or the "open" text is passed by another, I never pass anything else

to the script, so my condition in my script is "If [ Exact ( Get (

ScriptParameter ) ; "open"] " ... "Else #date stuff goes here".

[Ender]

Isempty ( get ( scriptparameter ) ) works for me.

[Ender]

Isempty ( get ( scriptparameter ) ) works for me.

[Ender]

Isempty ( get ( scriptparameter ) ) works for me.

[MoonShadow]

Valuable input, Rob, thank you so much. I will certainly use all of your ideas.

Well Mike, that's ONE of the problems then - spaces, because my tests were returning not IsEmpty when nothing is displayed.

I think I've blown it by treating Script Parameters like a clipboard, even so far as to copy and paste pictures from one location to the other (containers). I liked the fact that I could store data, graphics etc. in them and not affect the User clipboard.

Is there a text limit it will hold? I assumed it would respond (and hold the same amount as a normal field limit).

But, because I'm using them so creatively, I'll need to run the same types of tests on them as I would any other 'field.' I don't want to give up my creative pursuits ... but I need to be sure I'm very clear on how it's used and provide safe-guards. Or should I limit my use of them to more controllable (and critical) tasks, such as passing IDs?

[MoonShadow]

Valuable input, Rob, thank you so much. I will certainly use all of your ideas.

Well Mike, that's ONE of the problems then - spaces, because my tests were returning not IsEmpty when nothing is displayed.

I think I've blown it by treating Script Parameters like a clipboard, even so far as to copy and paste pictures from one location to the other (containers). I liked the fact that I could store data, graphics etc. in them and not affect the User clipboard.

Is there a text limit it will hold? I assumed it would respond (and hold the same amount as a normal field limit).

But, because I'm using them so creatively, I'll need to run the same types of tests on them as I would any other 'field.' I don't want to give up my creative pursuits ... but I need to be sure I'm very clear on how it's used and provide safe-guards. Or should I limit my use of them to more controllable (and critical) tasks, such as passing IDs?

[MoonShadow]

Valuable input, Rob, thank you so much. I will certainly use all of your ideas.

Well Mike, that's ONE of the problems then - spaces, because my tests were returning not IsEmpty when nothing is displayed.

I think I've blown it by treating Script Parameters like a clipboard, even so far as to copy and paste pictures from one location to the other (containers). I liked the fact that I could store data, graphics etc. in them and not affect the User clipboard.

Is there a text limit it will hold? I assumed it would respond (and hold the same amount as a normal field limit).

But, because I'm using them so creatively, I'll need to run the same types of tests on them as I would any other 'field.' I don't want to give up my creative pursuits ... but I need to be sure I'm very clear on how it's used and provide safe-guards. Or should I limit my use of them to more controllable (and critical) tasks, such as passing IDs?

[Ender]

I'm afraid I can't advise on your creative persuits of script parameters. I just use them for passing boring keys and a little text for new record creation.

I suppose you could design some simple tests to see how much stuff it will let you pass as a parameter.

[Ender]

I'm afraid I can't advise on your creative persuits of script parameters. I just use them for passing boring keys and a little text for new record creation.

I suppose you could design some simple tests to see how much stuff it will let you pass as a parameter.

[Ender]

I'm afraid I can't advise on your creative persuits of script parameters. I just use them for passing boring keys and a little text for new record creation.

I suppose you could design some simple tests to see how much stuff it will let you pass as a parameter.

[Rob 7 Collins]

Valuable input, Rob, thank you so much. I will certainly use all of your ideas.

Well Mike, that's ONE of the problems then - spaces, because my tests were returning not IsEmpty when nothing is displayed.

I think I've blown it by treating Script Parameters like a clipboard, even so far as to copy and paste pictures from one location to the other (containers). I liked the fact that I could store data, graphics etc. in them and not affect the User clipboard.

Is there a text limit it will hold? I assumed it would respond (and hold the same amount as a normal field limit).

But, because I'm using them so creatively, I'll need to run the same types of tests on them as I would any other 'field.' I don't want to give up my creative pursuits ... but I need to be sure I'm very clear on how it's used and provide safe-guards. Or should I limit my use of them to more controllable (and critical) tasks, such as passing IDs?

You're welcome.

You say an issue you run into is getting a match on not IsEmpty() when there is only spaces ... that you want to count that as empty.

You can account for that with Trim:

IsEmpty(Trim(fieldName))

But, be careful with this. If you are sure no user could ever make legitimate use of white space fields, you're probably safe in using it. If that is the case though, you probably want instead to define an auto-enter calculation to Trim the current value, in the field's options.

And alas, you are better off using keys. This is from the "Perform Script script step" help page:

Use script parameters to pass text or numbers into a script.

But you can could create a scratch_table, rather like the table I mentioned before to tell the type of data, and pass keys around for any kind of data you want to pass. Instead of using Copy and Paste and fussing with saving and restoring the user's clipboard, you could use Insert From Last Visited and Insert Calculated Result.

[Rob 7 Collins]

Valuable input, Rob, thank you so much. I will certainly use all of your ideas.

Well Mike, that's ONE of the problems then - spaces, because my tests were returning not IsEmpty when nothing is displayed.

I think I've blown it by treating Script Parameters like a clipboard, even so far as to copy and paste pictures from one location to the other (containers). I liked the fact that I could store data, graphics etc. in them and not affect the User clipboard.

Is there a text limit it will hold? I assumed it would respond (and hold the same amount as a normal field limit).

But, because I'm using them so creatively, I'll need to run the same types of tests on them as I would any other 'field.' I don't want to give up my creative pursuits ... but I need to be sure I'm very clear on how it's used and provide safe-guards. Or should I limit my use of them to more controllable (and critical) tasks, such as passing IDs?

You're welcome.

You say an issue you run into is getting a match on not IsEmpty() when there is only spaces ... that you want to count that as empty.

You can account for that with Trim:

IsEmpty(Trim(fieldName))

But, be careful with this. If you are sure no user could ever make legitimate use of white space fields, you're probably safe in using it. If that is the case though, you probably want instead to define an auto-enter calculation to Trim the current value, in the field's options.

And alas, you are better off using keys. This is from the "Perform Script script step" help page:

Use script parameters to pass text or numbers into a script.

But you can could create a scratch_table, rather like the table I mentioned before to tell the type of data, and pass keys around for any kind of data you want to pass. Instead of using Copy and Paste and fussing with saving and restoring the user's clipboard, you could use Insert From Last Visited and Insert Calculated Result.

[Rob 7 Collins]

Valuable input, Rob, thank you so much. I will certainly use all of your ideas.

Well Mike, that's ONE of the problems then - spaces, because my tests were returning not IsEmpty when nothing is displayed.

I think I've blown it by treating Script Parameters like a clipboard, even so far as to copy and paste pictures from one location to the other (containers). I liked the fact that I could store data, graphics etc. in them and not affect the User clipboard.

Is there a text limit it will hold? I assumed it would respond (and hold the same amount as a normal field limit).

But, because I'm using them so creatively, I'll need to run the same types of tests on them as I would any other 'field.' I don't want to give up my creative pursuits ... but I need to be sure I'm very clear on how it's used and provide safe-guards. Or should I limit my use of them to more controllable (and critical) tasks, such as passing IDs?

You're welcome.

You say an issue you run into is getting a match on not IsEmpty() when there is only spaces ... that you want to count that as empty.

You can account for that with Trim:

IsEmpty(Trim(fieldName))

But, be careful with this. If you are sure no user could ever make legitimate use of white space fields, you're probably safe in using it. If that is the case though, you probably want instead to define an auto-enter calculation to Trim the current value, in the field's options.

And alas, you are better off using keys. This is from the "Perform Script script step" help page:

Use script parameters to pass text or numbers into a script.

But you can could create a scratch_table, rather like the table I mentioned before to tell the type of data, and pass keys around for any kind of data you want to pass. Instead of using Copy and Paste and fussing with saving and restoring the user's clipboard, you could use Insert From Last Visited and Insert Calculated Result.

[Jodin]

okay but for some reason (lack of sleep?) i'm not seeing how to do this one:

how do i use a subscript to create and then pass it's parameter up to it's parent script? i envision breaking down my scripts into various logical calls that return a result without using globals for storage.

for instance, my 'new record' script could look like:

make new record

go to first field

pause script (click button to continue)

perform subscript 'validate data'

-(validate data sets a parameter based on it's findings)

if get(scriptparameter)="Y"

do something

else do something else

it seems so obvious but alas i can't figure it out. any hints here?

[Jodin]

okay but for some reason (lack of sleep?) i'm not seeing how to do this one:

how do i use a subscript to create and then pass it's parameter up to it's parent script? i envision breaking down my scripts into various logical calls that return a result without using globals for storage.

for instance, my 'new record' script could look like:

make new record

go to first field

pause script (click button to continue)

perform subscript 'validate data'

-(validate data sets a parameter based on it's findings)

if get(scriptparameter)="Y"

do something

else do something else

it seems so obvious but alas i can't figure it out. any hints here?

[Jodin]

okay but for some reason (lack of sleep?) i'm not seeing how to do this one:

how do i use a subscript to create and then pass it's parameter up to it's parent script? i envision breaking down my scripts into various logical calls that return a result without using globals for storage.

for instance, my 'new record' script could look like:

make new record

go to first field

pause script (click button to continue)

perform subscript 'validate data'

-(validate data sets a parameter based on it's findings)

if get(scriptparameter)="Y"

do something

else do something else

it seems so obvious but alas i can't figure it out. any hints here?

[Ender]

how do i use a subscript to create and then pass it's parameter up to it's parent script?

You can only pass script parameters from a button to a script or a parent script to a sub-script. You'll have to use globals to go the other way.

[Ender]

how do i use a subscript to create and then pass it's parameter up to it's parent script?

You can only pass script parameters from a button to a script or a parent script to a sub-script. You'll have to use globals to go the other way.

[Ender]

how do i use a subscript to create and then pass it's parameter up to it's parent script?

You can only pass script parameters from a button to a script or a parent script to a sub-script. You'll have to use globals to go the other way.

[Rob 7 Collins]

okay but for some reason (lack of sleep?) i'm not seeing how to do this one:

how do i use a subscript to create and then pass it's parameter up to it's parent script? i envision breaking down my scripts into various logical calls that return a result without using globals for storage.

Well, as has already been said, you can't. What you can do is, in the parent script, create a record in a table you will use as a scratch pad. Pass the child script the key for an entry in the scratch pad table. The child creates the value it wants and puts it in the scratch table, in the record with the key value equal to the parameter passed to it. The child script ends, the parent script resumes; in the parent script you can access the data created by the child script by referencing that key (the one the parent script created, so you will have to keep track of it).

To let the child script pass any data type, you need a field in the scratch pad table for each base data type (number, text, date, ..?) -- this will only let you pass a known number of variables from child to parent. To pass an unkown number of variables, it is slightly more complex:

The scratch pad has three extra fields now, "Serial" (just a number, not autoentered or anything), Index (again just a number), and "Key" (autoentered number). Parent creates two records in the scratch pad. The first record's Serial is set to the Key value for that record. The second record's Serial is set to the Key value of the first record (same value).

Call the child script, pass that same value again (Serial), as a parameter. Child creates as many values as it likes, always setting Serial to the recieved parameter, and setting index to whatever you like (this way you can pass multiple groups of unknown values -- it is a sort, but it is required to always be set). For each uncounted group, the child incriments the number field of the second record that the parent created: this let's you keep track of empty uncounted groups. Child script ends, parent resumes. Find all with not IsEmpty(Index) and Serial = that_serial_yet_again ...

...the only reason for the parent to create two records is one of style and preference. The first record is a marker, a way of grouping all child-created data. The second record is a counter, a way of counting all the sets (uncounted groups) created by the child. They could actually do both things at once, the parent only setting one record.

Also, you could formulate a way to make the intent of those uncounted groups variable. For example, say your child script creates:

{1,2,1,2}

{A,A,C,C}

{title1,title2,title3,title4}

{body1,body2,body3,body4}

The rendering intent is to create a catalog, with entries/categories like:

Section C

============

1: title3

body3

Your script has to know that the first set is entry number, the second set is category, and so on. In a case where the child script can pass individual parts of the catalog, without completing the catalog entries, your parent script has to be able to differentiate them. To make room for this you just need a "Intent" field in your scratch pad.

[Rob 7 Collins]

okay but for some reason (lack of sleep?) i'm not seeing how to do this one:

how do i use a subscript to create and then pass it's parameter up to it's parent script? i envision breaking down my scripts into various logical calls that return a result without using globals for storage.

Well, as has already been said, you can't. What you can do is, in the parent script, create a record in a table you will use as a scratch pad. Pass the child script the key for an entry in the scratch pad table. The child creates the value it wants and puts it in the scratch table, in the record with the key value equal to the parameter passed to it. The child script ends, the parent script resumes; in the parent script you can access the data created by the child script by referencing that key (the one the parent script created, so you will have to keep track of it).

To let the child script pass any data type, you need a field in the scratch pad table for each base data type (number, text, date, ..?) -- this will only let you pass a known number of variables from child to parent. To pass an unkown number of variables, it is slightly more complex:

The scratch pad has three extra fields now, "Serial" (just a number, not autoentered or anything), Index (again just a number), and "Key" (autoentered number). Parent creates two records in the scratch pad. The first record's Serial is set to the Key value for that record. The second record's Serial is set to the Key value of the first record (same value).

Call the child script, pass that same value again (Serial), as a parameter. Child creates as many values as it likes, always setting Serial to the recieved parameter, and setting index to whatever you like (this way you can pass multiple groups of unknown values -- it is a sort, but it is required to always be set). For each uncounted group, the child incriments the number field of the second record that the parent created: this let's you keep track of empty uncounted groups. Child script ends, parent resumes. Find all with not IsEmpty(Index) and Serial = that_serial_yet_again ...

...the only reason for the parent to create two records is one of style and preference. The first record is a marker, a way of grouping all child-created data. The second record is a counter, a way of counting all the sets (uncounted groups) created by the child. They could actually do both things at once, the parent only setting one record.

Also, you could formulate a way to make the intent of those uncounted groups variable. For example, say your child script creates:

{1,2,1,2}

{A,A,C,C}

{title1,title2,title3,title4}

{body1,body2,body3,body4}

The rendering intent is to create a catalog, with entries/categories like:

Section C

============

1: title3

body3

Your script has to know that the first set is entry number, the second set is category, and so on. In a case where the child script can pass individual parts of the catalog, without completing the catalog entries, your parent script has to be able to differentiate them. To make room for this you just need a "Intent" field in your scratch pad.