Using a script variable in a field rule...

[mbmonk]

Ok here is my problem. I need to use a global script variable ( called shp2a ) in the default value expression.

The problem I am having is that the default value expression does not recongise where the variable (shp2a) is located and kicks and error about unrecognisable varaible error. I understand why its kicking the error but I dont know how to solve it.

Here is the default value expression I am using:
if(shp2 "" 'BRKR', "t", shp2a)


How can I specify to A5v6 that shp2a is a global script variable?


I will be glad to post any file or information needed. Just ask.


Thanks for taking the time to look at this question.

Mike Monk

[Steve Workings]

RE: Using a script variable in a field rule...

Go back and define your table structure again. Click on the Variables icon on the toolbar and set the variable up there as well.

- Steve

[mbmonk]

RE: Using a script variable in a field rule...

Just for additional information, the script will always be ran before the user enters a new record into the table so shp2a should exist in memory even if its blank.

[mbmonk]

RE: Using a script variable in a field rule...

Thank You Steve.

Solved that problem in a rather quick fashion. Thank You Sir!

I am still trying to get my balance in the A5 developement enviroment.

[[email protected]]

RE: Using a script variable in a field rule...

I would dim that variable as part of the autoexec script.

Bill Belanger

[mbmonk]

RE: Using a script variable in a field rule...

Ok. I thought that solved my problem but it did not.

I have attached an experimental table with 2 field and tried to define the field rule as stated above.

not sure why its not working. Take a look at your leisure.

[mbmonk]

RE: Using a script variable in a field rule...

I would prefer not to set it up in my autoexec. This variable wont always be used every session and there are about 12 variable I have to use like this.

I just dont want to waste system resources if possible.

[mbmonk]

RE: Using a script variable in a field rule...

I guess the question i now have is can you just put the global variable name in the default field expression?

I created a globabl variable called shp2a.

The default value expression i have:
shp2a



It says it evaluates to a character and it even shows the value I assinged to shp2a when I am in the "expression builder". But when I try to save the field rules, It says it can't find the field shp2a. Which is correct its not a field its a global variable.


I am sorry to be spamming the board with this issue.

[mbmonk]

RE: Using a script variable in a field rule...

OK I FINAALLY got how to use the global variable.

In the "expression builder" you have to press F6 to bring up the Variables menu ( the option isnt shown on my expression builder ) but it does work if you hit F6.

This is how you specify variables not fields in the expression builder for field rules:
Var-"varaibleNameHere


Thanks for all the help guys :)

[Jim Chapman]

RE: Using a script variable in a field rule...

Hello Mike,

""This variable wont always be used every session and there are about 12 variable I have to use like this. ""

I'm jumping into this thread late, but have a couple of thoughts. First 12 variables would not be any overhead to be concerned about.

Another way to go about this that will give you much more flexibility would be to create a User Defined Function (UDF). A UDF can be used in almost all places that a regular built-in A5 function can be used. So you could create a UDF that first checks for the existance of your variable, and if it exists, returns the value, otherwise it could return "" or nothing. Then you just put a function call in the field rule. Now rather than being limited to building expressions, which can get messy if they are long, you now have all the power of Xbasic and or Action Scripting available to create your field rule expressions.

Good luck,
Jim

[mbmonk]

RE: Using a script variable in a field rule...

That is a great idea. I think I will look into that as it will solve my problems in possibly the best way.


I took C++ programming classes and they just drilled into my head GLOBALS = BAD. So I try to avoid them at all times if possible. If the situation calls for a global I use them, but if I can get away without it I will.

Thanks for the idea and explination.

[G Gabriel]

RE: Using a script variable in a field rule...

Mike:
I am not following nor understanding your logic:
Stop and think about this for a minute:
1-If the default value of a field is the outcome of an expression, and
2-If the outcome of the expression depends on the value of a variable, then
One must wonder, what sets the value for that variable? The answer most likely would be: Some parameters, some other field value(s), or some user's input, right?
If the outcome of the expression depends on the variable and the variable depends on one or more of those parameters, wouldn't be logical to make the expression dependant on those parameters in the first place?
Can you outline how is the value of this variable determined??
Thanks
Gabe

[Jim Chapman]

RE: Using a script variable in a field rule...

Hello Mike,

""I took C++ programming classes and they just drilled into my head GLOBALS = BAD""

:-) I wouldn't phrase them as "BAD", but in general don't declare a variable as global unless it is really needed.

IMHO, the issue is not overhead, although I suppose if you were declaring 10's of thousands, it might become as issue. The issue is persistence of the values. For instance, Alpha has several built-in variables, specifically they have the:

query.*

dot variable family to pass info to the TablePointer.query_create() method. So if you do:

t1 = table.open("table1")
query.filter = "FieldName = 'My Data'"
t.query_create()

You have sucessfully executed a query on table one. Now in some other location you define:

t2 = table.open("table2")
t.query_create()

Forgetting to redefine the global query.filter for the second situation, the query on the second table will be in error.

Another common situation with globals is that you declare multiple variables in various places in the app. You forget that you have already dim'med a variable named: MyVariable, now later on you dim another variable with the same name. If they are globals, you second declaration and assigned value could effect the procedure you have in place using the first variable, etc, etc.

So in general, don't use globals unless it is appropriate to use them :-) ie: use them sparingly.

Good luck,
Jim

[neecy]

Re: Using a script variable in a field rule...

Hello Jim-

The advice about setting up UDF and Action script is probably what I need. I am having the exact same problems except I have about 50 fields in which the possibility of the field name and value will not be present. Will I have to set this up for each field as well as the variables I create? Also I have another question. After my fields populate to my form with the correct values, I inted to export to an Excel file. The new variables I created on my form and setup Action scripting to will have to be included in the export since I intend to reference this file and all the fields (variables) to more than a dozen spreadsheets. Will my variables show when I export? You might have to talk me through this since I have only been using Alpha 5 database for 1 month.

I am updating my details above. I am setting my table to crosstab procedure to provide the date as the row, and 4 other field names concatenated together as my column name. I am summarizing on quantity. So far, so good and my tables are calculating correctly. I am establishing my crosstab table to a form and realize that not all of my fields are generated because it's based on the data entered. How do I go about setting my forms to the new variable names I am establishing for when these values are generated through my crosstab procedure, they will import the values to these variables. I need to understand the process of using Action scripting, xbasic, or UDF.

Sorry if I am redundant or long-winded. :)

Thanks-

Neecy

[Stan Mathews]

Re: Using a script variable in a field rule...

Will my variables show when I export?

No. The export methods only allow you to export table fields.