I too am trying to decide whether to port my AREV app to OI. Actually there is no real benefit other than sooner or later AREV may or may not run on future OS's. I have a lot of catch up to do but decided to download the latest demo to seehow it compares to V3.4 which is the last version I have before leaving the works program. So I certainly am not as proficient on OI as AREV but one thing that was real simple in AREV is not simple at all in OI (or at least I can't get it to work)

In Arev I wrote a UDC routine that would check for a number and store it to whatever accuracy the user typed in, but would display it to a specific number of digits that changed from form form (it would also do rounding correctly as some earlier version of AREV seem to have a problem with that). On some forms for some users, the number is displayed as xxxxx's to mask it. For example, a user might type in 1.2456 and one form might be set to display 1 ( no decimals); another might be set for 2 decimals showing 1.25 another might be set to show the entire number another form might masked it totally with xxxx's if the user's security level is not high enough. But the data was always stored exactly as the user typed it in - in this case it was stored as 1.2456 (this was the way is was done in the original non-AREV database that was converted to AREV, and I did not want to change exisiting data).

The conversion routine worked great in AREV, but in OI problems. And it seems OI32 4.x operates a little bit differetnly than OI 3.4

In OI32 I made a new form with 3 edit lines labled ID , field1, field2.

In field1, I attached the following VALID_TEST UDC to the validation part of the edit line property.

In field1, I attached the following CONV_TEST UDC to the conversion/display part of the edit line property.

No other quickevnts or scripts are being used onthe form.

The VALID_TEST UDC is:

COMPILE SUBROUTINE VALID_TEST(CHARSTR CONV, CHARSTR IN_VAL, CHARSTR | SUB_BRANCH, CHARSTR RET_VAL)

VAL=IN_VAL

RET_VAL='

IN_VAL='

BEGIN CASE

CASE CONV= "ICONV"

RET_VAL=GOODBYE"

CALL MSG(@WINDOW, "VALID - ICONV IN_VAL =:VAL:"     RET_VAL=:RET_VAL)

CASE CONV=OCONV"

RET_VAL=NEVER"

CALL MSG(@WINDOW, "VALID - OCONV IN_VAL =:VAL:" RET_VAL=:RET_VAL)

CASE 1

CALL MSG(@WINDOW, " VALID - CASE 1  IN_VAL =:VAL:" | RET_VAL=:RET_VAL)  

END CASE

RETURN

The coversion test routine is:

COMPILE SUBROUTINE CONV_TEST(CHARSTR CONV, CHARSTR IN_VAL, CHARSTR | SUB_BRANCH, CHARSTR RET_VAL)

VAL=IN_VAL

RET_VAL='

IN_VAL='

BEGIN CASE

CASE CONV= "ICONV"

RET_VAL=YESTERDAY"

CALL MSG(@WINDOW, "IN CONV - ICONV IN_VAL =:VAL:" |  RET_VAL=:RET_VAL)

CASE CONV=OCONV"

RET_VAL=TODAY"

CALL MSG(@WINDOW, "IN CONV - OCONV IN_VAL =:VAL:" | RET_VAL=:RET_VAL)

CASE 1

CALL MSG(@WINDOW, "IN CONV - CASE 1  IN_VAL =:VAL:"|  RET_VAL=:RET_VAL)  

END CASE

RETURN

So here is the testing I did to try and understand what is going on. I am trying to determine the order of event processing and what happens as the values go in and come out of the UDC. So I change the return value and issue messages to track the process

So here is what I found:

for a record 1 already stored on disk field 1 has Tree

scernio 1:Read old record that has field 1 (not key field) filled with "Tree" and going to leave this field alone but change field2 then save the record:

Enter record ID & record is read

 CONV_TEST Oconv branch is used

In_val=Tree    Ret_Val=Today 

 field display Today 

Change a field 2 ( to force a write) and do nothing to field 1 (our test field) and save record. Upon saving the following happens:

    CONV_TEST Iconv branch is called

 In_val=Today   Ret_Val=Yesterday 

    CONV_TEST Iconv branch is called AGAIN

In_val=Today   Ret_Val=Yesterday 

form clears 

Upon checking the record, the value in field 1 is still Tree as

would be expected since we did not change the field. This actuall works like I want - Tree is not displayed to the user but Today is. But since we did not change field 1 the value on disk did not change

Scernio 2:Read old record that has field 1 (not key field) filled with "Tree" and going to change this field and another one (just to make sure the record is being saved correctly):

Enter record ID & record is read

   CONV_TEST Oconv branch is used

In_val=Tree  Ret_Val=Today 

   Field shows Today 

Now change field from Today to ZXC by typing in ZXC

   VALID_TEST Iconv branch is used

In_val=ZXC  Ret_Val=Goodbye 

   CONV_TEST Oconv branch is used

In_val=Goodbye Ret_Val=Today 

   Display changes back to Today

Change another field as a control

Now save the record

   CONV_TEST Iconv branch is used

In_val=Today  Ret_val=Yesterday

   CONV_TEST Iconv branch is used AGAIN

In_val=Today  Ret_val=Yesterday

Form clears

View the record via system editor: Tree is STILL in the field - nothing has changed. Tree was the original value. The other field used as control did in fact change to the new value to the record is being saved.

So obviously I am missing something simple or UDC in OI do not work as I expected. My guess is whenthe form intializes Tree is put somewhere and field 1 is set to "Today" the alternate form of data. when i cahnge the data to "ZXC" this value is not being kept anywhere. When the record is saved the value of field1 is still "Today" so the value is not cahnged (or somethign like that).

Question 1 Why is the CONV_TEST Iconv branch called twice?

Question 2 How does the RET_VAL parameter interact with the form?

Question 3 I know @RECORD is not really updated dynamically but is there a variable that is?

Can anyone shed some light on this. I apologize for the length of the post and my ignorance.

Thanks

ed

Question 1 Why is the CONV_TEST Iconv branch called twice?…

OI seems to call your UDC when "validating" and then when "converting" (oconv).

Question 2 How does the RET_VAL parameter interact with the form?

OI replaces the RET_VAL with the user entry on the form, if you have the UDC set up as a "conversion" for that control.

Question 3 I know @RECORD is not really updated dynamically but is there a variable that is?

Nope! Hmmmm… take a loop at the "POS" property in chapter 4 properties. That should explain the basic way to gather info.

Thanks Richard,

]Question 1 Why is the CONV_TEST Iconv branch called twice?…

]

]OI seems to call your UDC when "validating" and then when "converting" ](oconv).

I thought when validating data it would use the routine speceified VALIDATION section. I thought that what was happening so that is why I have different routines for each just to check it out! Seems strange this woudl be the program flow

]Question 2 How does the RET_VAL parameter interact with the form?

]

]OI replaces the RET_VAL with the user entry on the form, if you have ]the UDC set up as a "conversion" for that control.

So bascially what you are telling me that anything you do with in the UDC has not effect? I can see that OI replaces the IN_VAL with user input.

]Question 3 I know @RECORD is not really updated dynamically but is ]there a variable that is?

]

]Nope! Hmmmm… take a loop at the "POS" property in chapter 4 ]properties. That should explain the basic way to gather info.

I can see how the UDC would work in the normal situation where the data remains on the form but just formatted differently, so the ICONV part of the conversion can turn it back into the internal form. But if what ever is being displyed is different from the actual data entered, ie all but last 4 digits of a credit card or SSN are masked, then it sounds like I will have to be responsible for tracking the actual data the user entered (and what the orginal value was on disk) and replacing the masked data with the original value. Correct?

ed

The code get's called, but the effects are different. Try working with PHONE_FORMAT and see how things are displayed.

You may find you will have different results if you do not use MSG and instead display what you wish in a different window control. Focus logic like that upsets validation logic and got/lostfocus handling.

As for @RECORD, the info is stored in the INVALUE property, and that is what is used to populate @RECORD. Before any event code is run, the system will generate @RECORD for you. I haven't seen it fail for a good number of release versions.

The Sprezzatura Group

World Leaders in all Things RevSoft

View this thread on the forum...