RE: Now UDFs in default value?
Hi Gabe,
"Do the same rules apply to UDF?" Yes
"I did notice something with Cal's app though: if you create a form based on that table, insert base_reg as an object on the form for the sake of testing, close and re-open the DB, base_reg will show as an error (object refers to non existing field). On the other hand, if before you open the form, open the default browse then switch to the form, base_reg will take the proper value."
Once a new record is entered and you pass through the field rule, the event or default field rule is evaluated, which causes the function call which creates the session (shared) variable.
"1-When you open the default browse and since the the first tab field is the one with the field rule, the script runs, creates and sets the value to base_reg but somehow the chain breaks somewhere down the line"
Answered above.
"2-At least the first part of the script is correct and either something other than the script itself is getting in the way of it's completion, or there is something wrong with the script down the line"
I explained the problem with the code (the table open)
"3-openeing the form did not even trigger the first part of the script that we know is correct, why?"
It does start the script. See my code above. In worst case scenario's of debugging (occasionally seen by myself and others), errors weren't able to be duplicated by using debug or other similar methods. My solution is to set a global variable to various values along the way.
e.g
dim global step as c
step="1"
more code
step="2"
more code
step="3"
etc.
Then I can check what the last value of step was after the code was executed. You can also use ui_msg_box to display the values along the way, but this sometimes gets in the way.
Regards,
Ira
Hi Gabe,
"Do the same rules apply to UDF?" Yes
"I did notice something with Cal's app though: if you create a form based on that table, insert base_reg as an object on the form for the sake of testing, close and re-open the DB, base_reg will show as an error (object refers to non existing field). On the other hand, if before you open the form, open the default browse then switch to the form, base_reg will take the proper value."
Once a new record is entered and you pass through the field rule, the event or default field rule is evaluated, which causes the function call which creates the session (shared) variable.
"1-When you open the default browse and since the the first tab field is the one with the field rule, the script runs, creates and sets the value to base_reg but somehow the chain breaks somewhere down the line"
Answered above.
"2-At least the first part of the script is correct and either something other than the script itself is getting in the way of it's completion, or there is something wrong with the script down the line"
I explained the problem with the code (the table open)
"3-openeing the form did not even trigger the first part of the script that we know is correct, why?"
It does start the script. See my code above. In worst case scenario's of debugging (occasionally seen by myself and others), errors weren't able to be duplicated by using debug or other similar methods. My solution is to set a global variable to various values along the way.
e.g
dim global step as c
step="1"
more code
step="2"
more code
step="3"
etc.
Then I can check what the last value of step was after the code was executed. You can also use ui_msg_box to display the values along the way, but this sometimes gets in the way.
Regards,
Ira
Comment