UDC's in OI

Michael

Hello all,

I am perplexed about the behavior of a UDC (User-Defined Conversion) in OI. The UDC in question does a translation of a value based on the contents of a table. For example, a code of "J" should display as "Joe's Bar and Grill" from a location table. I am doing a standard [Program, Branch] UDC where Branch is the table from whence to get the value. The goal is to have an internal value of "J" while displaying as "Joe's Bar and Grill" (this is just an example).

The UDC works great for reports and such. The problem is in entry forms. I am selecting a value from a popup and putting the value into the INVALUE for an editline. Debugging the LOSTFOCUS event, it seems to work: INVALUE shows "J" and TEXT and DEFPROP show "Joe's Bar and Grill". When I go back to the editline, debug shows that INVALUE, TEXT and DEFPROP all show "Joe's Bar and Grill"; and if the record is saved, the full description is saved in the record.

This is different situation than a [PHONE_FORMAT] or Date conversion, because there is no good way to take an OCONV'ed description and ICONV back to a code.

This used to be easy enough in Arev. I'm sure there is some really simple way to accomplish this.

Any thoughts?

Thanks!

DonBakke

Michael,

As I was reading your question I remembered writing an article that deals with the basic requirements. Please review this blog post and let me know if you need any further assistance.

Michael

Hi Don,

I actually did read your article before, and I am following your basic framework. A simple conversion like that would not be a problem, because it's easy to both Oconv and Iconv. In this case, the Oconv'ed value is read from a table, and there is not a good way to Iconv back.

It looks like OI is doing the Oconv on entry, and then is re-Oconv'ing the translated value, and storing that because it can't Iconv.

I thought Invalue was supposed to be the internal data. Should I be putting the value returned from the popup somewhere else? How do I avoid storing the Oconv'ed value?

Thanks,

Michael

DonBakke

Hi Michael,

You could, perhaps, use a global common. You can then create a reverse lookup so that the Oconv value (i.e., verbose word) becomes the "key" and the Iconv value (i.e., code) becomes the "value". This also assumes you'll never have any duplicates. That is, you must have a strict one-to-one relationship in your database.

The only other way I can think of doing this is to have a companion database (or index) that does a reverse association and your UDC pulls from this.

Michael

Thank you sir.. This was so easy to do in Arev..

Michael

Just curious.. the only time the Iconv will happen is in a form. Sh/could I put the Iconv value in a UD property in the control? (Say, @INVAL or some such)

DonBakke

Michael,

There is a slight different with ICONV/OCONV processing in OI versus AREV. I don't think it made AREV easier, just different. Otherwise, I find UDCs in AREV and OI to work the same. At least, our UDCs seemed to translate between AREV and OI without any problems.

I highly recommend against using a UDP. If you were going to do that, then why not go with a global common? That would be just as easy and it would be more portable. You never know when your UDC will be used outside of a form context so it is not worth the risk. I am also convinced that UDCs should be able to work as independently as possible.

Having said that, even a global common solution has problems. It presupposes you will always have the Key ID/Value relationship stored in advance. This, I believe, would also be a problem with your UDP solution. So, the only way for these solutions to work is to have a process that seeds these reverse-lookup lists completely upon first usage. Depending upon the size of the database, this could cause a lag in the application that would be unexpected.

If I were to do this myself, I would create an MFS that maintains the reverse lookup arrays and store these in the table similar to the way a QuickDex works. Then the associated lists of Key IDs and Values will always be maintained and available to your UDC in all cases.

Michael

Thank you sir!

Michael

Hola.. the plot thickens. I've used the common variable solution, and it works like a charm Except that I get an error message: 'The validation requirement enforced by the User Conversion Subroutine "...."'. The technique does work otherwise.

If I set Status() = 0, I get no error msg, But the conversion doesn't work. If I set Status() to 1, it works but I get the error msg.

Any suggestions?

Gratzi!

DonBakke

Michael,

I think I would need to see your code. Setting Status() to 1 tells the UDC that you have an error (Bad Data).

There is another option I forgot to mention. It's how we worked around the need for both storing a global command and creating a reverse-lookup MFS: combine the code and description in the OCONV value. Take a look at this screenshot:


All three of those edit lines are using the same UDC to display a "name" and a "Key ID" from different database tables. Like you, we are passing the relevant information through the Branch argument. The trick is that by keeping the Key ID in the OCONV value, we have a reliable way to extract the key (without having to rely upon storing it elsewhere) in the ICONV logic. Our Branch argument also supports whether the Key ID is pre-pended (which you can see in the Product edit line) or appended (which you can see in the Supplier and Document edit lines).

Michael

Thanks Don.. I'll send you the code offline. It's just weird that the conversion works if I set Status() to 1.

I thought about doing what you describe, but the client wants to see the same result as before. Most of the "conversion" programs are called with @S .... and the results are slammed into @Ans. And most don't have the key as part of the output.