What is my Script Parameter?

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

[Jodin]

ahh *******, ok. i'll have to weigh whether using globals for this storage outweighs putting the logic directly into the script. i'm thinking more about debugging and duplication - i've been afforded the rare opportunity for a rewrite and i want to normalize my script code as much as possible -- put all the shared calls into subscripts, etc..

[Jodin]

ahh *******, ok. i'll have to weigh whether using globals for this storage outweighs putting the logic directly into the script. i'm thinking more about debugging and duplication - i've been afforded the rare opportunity for a rewrite and i want to normalize my script code as much as possible -- put all the shared calls into subscripts, etc..

[Jodin]

ahh *******, ok. i'll have to weigh whether using globals for this storage outweighs putting the logic directly into the script. i'm thinking more about debugging and duplication - i've been afforded the rare opportunity for a rewrite and i want to normalize my script code as much as possible -- put all the shared calls into subscripts, etc..

[Rob 7 Collins]

Well, that was just to say you can do it. The last thing I'm talking about would be as powerful as passing n-dimensional hashes between functions in a solid programming language (albeit massively slower). Chances are, one of the first two would suffice

It certainly is bulky though.

[Rob 7 Collins]

Well, that was just to say you can do it. The last thing I'm talking about would be as powerful as passing n-dimensional hashes between functions in a solid programming language (albeit massively slower). Chances are, one of the first two would suffice

It certainly is bulky though.

[Rob 7 Collins]

Well, that was just to say you can do it. The last thing I'm talking about would be as powerful as passing n-dimensional hashes between functions in a solid programming language (albeit massively slower). Chances are, one of the first two would suffice

It certainly is bulky though.

[Oldfogey]

How about something like this?

NewRecScript

make new record

if (get scriptparamaeter) <> "Y" [or better some impossible thng like ZZ@#$%]

go to first field

pause script (click button to continue)

perform subscript 'validate data'

end if

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

In 'Validate Data'

perform script (NewRecScript("ZZ@#$%"))

exit script

(back in NewRecScript) ...

if get(scriptparameter)= "ZZ@#$%"

do something

else do something else

The full implementation is left as an exercise to the student.

[Oldfogey]

How about something like this?

NewRecScript

make new record

if (get scriptparamaeter) <> "Y" [or better some impossible thng like ZZ@#$%]

go to first field

pause script (click button to continue)

perform subscript 'validate data'

end if

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

In 'Validate Data'

perform script (NewRecScript("ZZ@#$%"))

exit script

(back in NewRecScript) ...

if get(scriptparameter)= "ZZ@#$%"

do something

else do something else

The full implementation is left as an exercise to the student.

[Oldfogey]

How about something like this?

NewRecScript

make new record

if (get scriptparamaeter) <> "Y" [or better some impossible thng like ZZ@#$%]

go to first field

pause script (click button to continue)

perform subscript 'validate data'

end if

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

In 'Validate Data'

perform script (NewRecScript("ZZ@#$%"))

exit script

(back in NewRecScript) ...

if get(scriptparameter)= "ZZ@#$%"

do something

else do something else

The full implementation is left as an exercise to the student.

[Rob 7 Collins]

if (get scriptparamaeter) <> "Y" [or better some impossible thng like ZZ@#$%

---

I'm lost on your psuedo code.

Do you mean:

if [ not Exact(Get(scriptparameter) ; "ZZ@#&%" ]

<> might fail in odd ways, at least if "Y" is a calculation

[Rob 7 Collins]

if (get scriptparamaeter) <> "Y" [or better some impossible thng like ZZ@#$%

---

I'm lost on your psuedo code.

Do you mean:

if [ not Exact(Get(scriptparameter) ; "ZZ@#&%" ]

<> might fail in odd ways, at least if "Y" is a calculation

[Rob 7 Collins]

if (get scriptparamaeter) <> "Y" [or better some impossible thng like ZZ@#$%

---

I'm lost on your psuedo code.

Do you mean:

if [ not Exact(Get(scriptparameter) ; "ZZ@#&%" ]

<> might fail in odd ways, at least if "Y" is a calculation

[Oldfogey]

Sorry, Rob. I've edited my original post. (About 5 minutes after I'd logged off I realised I'd left out the most important bit!)

The idea is to call your master script from your subscript using a parameter to indicate whether or not the editing was OK. You need to be 100% certain that the parameter passed from the subscript is something the user will not enter in the field you are validating. Hence the odd-looking literal.

Mind now in gear. Better than the "ZZ@#&%" would be to concatenate something on the front of the user's data - just a simply "ZZ". Then you can use "Y" and "N" without any chance of ambiguity.

See the attached.

[Oldfogey]

Sorry, Rob. I've edited my original post. (About 5 minutes after I'd logged off I realised I'd left out the most important bit!)

The idea is to call your master script from your subscript using a parameter to indicate whether or not the editing was OK. You need to be 100% certain that the parameter passed from the subscript is something the user will not enter in the field you are validating. Hence the odd-looking literal.

Mind now in gear. Better than the "ZZ@#&%" would be to concatenate something on the front of the user's data - just a simply "ZZ". Then you can use "Y" and "N" without any chance of ambiguity.

See the attached.

[Oldfogey]

Sorry, Rob. I've edited my original post. (About 5 minutes after I'd logged off I realised I'd left out the most important bit!)

The idea is to call your master script from your subscript using a parameter to indicate whether or not the editing was OK. You need to be 100% certain that the parameter passed from the subscript is something the user will not enter in the field you are validating. Hence the odd-looking literal.

Mind now in gear. Better than the "ZZ@#&%" would be to concatenate something on the front of the user's data - just a simply "ZZ". Then you can use "Y" and "N" without any chance of ambiguity.

See the attached.

Parameters.zip