I was wondering if anyone has come across anything like this (and yes, I did search the online discussion articles ):

AREV 3.12

I have a prompt which has an @S SUBROUTINE_NAME@ call for the validation. I started with a simple version of the subroutine, which worked fine.

Then I had to refine it to deal with other, dynamic variables. Essentially, the validation of the user-entry in this (dollar amount) field depends two factors: another dollar amount field {PAY_AMOUNT} contained within the same customer record and the state for the customer. {STATE} is a symbolic which uses the {ZIP} field in the customer record and XLATE's to a ZIPCODE table to find out what state that zipcode falls under. Since these fields can change along with the field that is being validated, I wanted to make sure that the validation subroutine read in the current values (which may or may not match what was actually stored in the record) when performing the validation.

Rather than to hard-code the formula for the {STATE} field or the position for the {PAY_AMOUNT} field by using @RECORD, I used curly braces within the subroutine to reference the dictionary items. The values were obtained correctly, and the validation occurred correctly, with STATUS() being set correctly and the error message being displayed if need be. However, regardless of whether the data was validated or not, the window would blank out the prompt being validated and then move on to the next prompt.

I got around this by hard-coding the references to the dictionary items (rather than using curly braces), and it's working okay. But I'm curious as to why this wouldn't work? I'm presuming it has something to do with something being reset somewhere along the way, probably within the WINDOW.COMMON stuff. Anybody have a good answer?

Thanks

Chip Fichot

Credit Master

While not offering an answer to your specific question, I must observe that it would be considered better to (as you say) "hard code" references to @RECORD, rather than use a dictionary call with curly braces. It is faster to execuste, and does not have to load the compiled dictionary call onto the programme stack.

J

@DICT, @RECORD, @ID, @ANS are probably getting stepped on. I noticed in version 2.0x that these variables would get stepped on, especially in low-string space conditions. Also 2.0x on did not seem to protect these variables as well as 1.1x did.

Try saving these variables prior to the xlates and restore them after.

Thanks for the responses. It actually dawned on me that the problem (I think) is @ANS, as it is used in the symbolics I was calling.

I agree and concur with the idea of hard-coding being 'better' from a pure programmatic standpoint. My reasoning behind using the dictionary is one of laziness . If I change the logic in the symbolic, then I don't have to look through the programs that are using the symbolic to re-program the logic within them.

Of course, an answer to that problem is that I create a function that both the symbolic and the validation program call so that all I have to do is change the function.

Thanks again for the input!

The normal drill (particularly if the code is being called from within a window) is:

Subroutine FOO

*

* save system vars so they won't get trashed

*

AT_DICT=@DICT

AT_ID =@ID

AT-REC =@RECORD

*

* SET UP ALL YOUR CALLS FOR LATER

*

@ANS='

VAR1={Var_1} ;* the assumption is that @RECORD,@ID,@DICT ARE OK HERE

* make sure things haven't changed just to be safe

@RECORD=AT_REC

@ID =AT_ID

@DICT =AT_DICT

VAR2={Var_2}

* do it again

@RECORD=AT_REC

@ID =AT_ID

@DICT =AT_DICT

FOO=XLATE('SOMEFILE',VAR1,"FIELD_NAME","X")

* remember to keep resetting your system variables after any call

* that might swap these items

* other calls / whatever

* you can even swap dicts and make calls there

@RECORD=AT_REC

@ID =AT_ID

@DICT =AT_DICT

* now do all your @RECORD housekeeping

RETURN

Don, I agree with Jonathan.

Use of {Var1} … is stack consuming and much slower …

It is acceptable only in case of symbolics, but I prefere not to nest symbolics.

There should be noted good practise (spped-up) when more symbolics in the table are related to the same record in another table … use named common to read the foreign record just once.

View this thread on the forum...