I have a timing problem with oconv data based on a field in the same record. The region_map control is an edittable with two columns. Column 1=numeric code, Column 2=description. I have another edittable that contains an association between clients & regions. I have looked at the controls, and @record and all are blank during the Oconv.

Here is the code:

   regions=get_property(@window:".REGION_MAP","INVALUE")

   Begin Case

      Case Conv=ICONV"

         val=Field(Ans," ",1)

         locate val in regions using @vm setting pos then

            return_data=val         

         end else

            call msg(@window,"Invalid Region")

            status()=invalid_nomsg$

         end

      Case Conv=OCONV"

         return_Data=ans

         locate ans in regions using @vm setting pos then

            return_Data=ans : " - ":regions

         end

   End Case

John,

My take on this is that you are manipulating data within a form context, and as part of that manipulation you are referencing @Record for data.

It is documented that @Record is a partial representation of what might be saved to record - if you want the full goods you need to read the contents of each control. Thus in your context you might well update the contents of @Record on the change of data in your other associated control.

regards Richard Bright

Understood. however, in this case if the form is specific and I am using get_property to extract the data. The problem seems to be that the controls are empty until the read logic has assigned them. It appears that the Oconv happens before the controls are assigned any data and therefore I don't have access to the info in this context.

I think I am going to move this array to another table, that way I will always have access to it via an Xlate.

John

John,

Now that you have said this, yes. Code/Description conversions in separate controls may have some display issues with the read process. I place the code and description in the same control, separated by a bar (|). The validation is performed against TEXT1,"|" to create INVALUE. The oconv to TEXT concatenates code|description.

Probably nobody else will like this solution, but it is consistent with how my AREV product interface worked, and it greatly reduces the number of controls required in a window.

So you are basically storing the code/description together? I was trying to get away from storing the description on each and every entry as this is redundant info. I think if I save my code and description into a separate table it will solve my problem.

John

John,

I have a CODES table which stores Code/Description lists as well as definitions for a multi-column Popout options display. I store only the codes in data tables. I have a user conversion, CNV_CODE,name, which on OCONV concatenates the code|description and on ICONV strips the code with TEXT1,"|". From the user's perspective the code and description display together in a control after the LOSTFOCUS, but the INVALUE is only the code. This may sound awkward but users think is works very smoothly.

Once the Works CD arrives, you can load the EDI*Atlas demo and see this work in about a thousand different entries. If you have feedback once you see it work, I would like to hear it.

Gerald

Thanks Gerald, looking forward to the Works CD.

By the way I have also used this technique quite extensively however, if the codes are stored in fields within the same record the Oconv does not work as the controls and @record have not been assigned data yet.

Moving the code/descrition to another associated table solved my problem.

John

I do something similar, but only display the description (just as in arev). A hidden databound table with NONE as validation/conv holds all data and a displayed table (an SRP OLE control) does all validation/conversion. This became necessary as iconv() could not always resolve to a unique value without user input due to the entries in code/desc table, which are user defined. No problem in arev, as it stores and manipulates only internal values - big problem in OI, where someone (foolishly) decided that manipulating the output converted data would always be best (forcing multiple validation/iconv calls to re-determine the true value of fields for programming, unless duplicate fields are maintained). Anyway, the data now displays just as arev users were used to, without the extra space needed in windows or reports to add that extra code info (and all handled by a few promoted events, unless extra manipulation of entries is needed, which is also easily done in a windows specific event module).

View this thread on the Works forum...