Greg James and I have been working on a very interesting problem with a UDC. I've done some testing and research on this website and have come to these conclusions regarding Validations and Conversions (some of this is old news, but restated for quick context):

1. Validations now only validate data whereas in AREV they used to also provide input conversion. Validation processing, however, still calls the UDC using "ICONV" as the Type parameter

2. Conversions now provide input conversion and output conversion, whereas in AREV we only had output conversion. Input conversion processing also calls the UDC using "ICONV" as the Type parameter and output conversion processing calls the UDC using "OCONV" as the Type parameter.

Now what is hitting us between the eyes about all of this is that a UDC can technically be called three times. Once by the validation process, and twice by the conversion process. This was discovered when a dialog box was placed within the ICONV process and it kept getting called twice. I finally figured out that it was getting called the first time by the Validation process (since it uses ICONV as Type) and then it was getting called again by the Conversion process (which also uses ICONV as Type when input converting.)

The interesting thing is that this doesn't always happen. Only when the data entered into the prompt is exactly what it looks like internally does the system called the UDC again using ICONV. Now I'm baffled. Since I now understand how OI calls UDC's, I would have expected the UDC to be called three times all the time. But it isn't. Why is it working this way?

In the meantime, we are attempting a workaround by adding an additional parameter to the UDC call so that the UDC can tell whether the ICONV type is being called from the Validation processor or the Conversion processor. It might not work, however, if the conversion processor doesn't consistantly call the UDC.

Thanks in advance for any ideas,

[email protected]

SRP Computer Solutions

This is the way i see it…

Validation…

Use ICONV function and the STATUS() value for validation. for example to validate a date entry in the old days you would ICONV it and if STATUS() was not 0 then an invalid date was entered.

Conversion…

Use ICONV function first, then use OCONV function to get the user entry to look uniform to the conversion. For example to accept a date entry in the old days you would ICONV it and verify the date to be valid. Then you would OCONV it to redisplay the user entry into a likeable display of a date. A very neat and very common and effective method of verification and display.

So i see why validation does what it does, and i see why conversion does what it does.

Richard,

I understand the premise of validation and conversion just fine. I'm struggling with what appears to be a minor bug in implementation. It is also possible that this UDC is doing something a bit unorthodox thereby creating a problem for us. Here is the situation:

This UDC only permits valid human temperature ranges. It will allow the temperature to be entered in Fahrenheit or Celsius. At the same time, it wants to know where the temperature was taken (Oral, Rectal, or Axillary.) It gets this information by calling a dialog box with radio buttons in the ICONV section. The temperature must always have a single decimal place entered as well.

All temperatures are eventually converted to Fahrenheit based on an Oral reading. This means that if 80.0 was entered and the user selects Rectal, the system will subtract one from 80.0 and return that value (i.e. 79.0). If the user entered 80.0 and selects Oral, the value is left alone.

The Validation/Input Conversion process only returns a number with one decimal point. The Output Conversion adds a "Oral °F" statement after the number. So a typcial output result would look like: 80.0 Oral °F. So far so good.

When the user enters a number and selects any option that changes the value of what was entered (like Rectal) then the ICONV process is only invoked once (from Validations) and then the OCONV process is invoked (from Conversions). This is great as the end user only sees the dialog box from the ICONV once.

However, when the user enters a Fahrenheit number and selects Oral (thereby leaving the number alone) then the ICONV process is invoked twice (once from Validations and once from Conversions) and then the OCONV process is called. This forces the dialog box to appear twice as well making this UDC work ineffeciently.

I suppose the fact that the UDC converts the number entered into a separate number under certain conditions is itself unorthodox, but I don't understand why it would force the skipping of the Conversion ICONV process. Either this is a small bug…or UDC should always assume that a Validation will not alter the data.

Anybody got any answers? Thanks.

[email protected]

SRP Computer Solutions

Hi Don,

Here is a post I made to Barry a while back:

If you use PHONE_FORMAT only as a validation and not conversion, and you enter aaabbbcccd you should get 1112223334 (or something like that) returned in the prompt…..er..shouldn't you.

That is not correct. Validation only validates … it is responsible for answering the following question:

1) Is the data as it was entered capable of being converted to a valid internal format of that data, for example is "(800)262-4747" capable of being the phone number "8002624747"?

Conversion is responsible for two questions:

1) Assuming the data is valid, what is the internal format of that data? For example "(800)262-4747" becomes "8002624747". This is ICONV.

2) What is the external format of the data? For example "8002624747" becomes "(800) 262-4747". This is OCONV.

In Arev, the window processor lumped the ICONV into the validation step. Apparently your UDC's assumed that ICONV and OCONV were the same so you only used the validation and didn't bother using the conversion capability.

Restating this, I am assuming that you misunderstood the purpose of the UDC in Arev. The functionality in Arev is split into VALID and CONV. In Arev, VALID had two answer two questions:

1) Is the data as it was entered capable of being converted to a valid internal format of that data, for example is "(800)262-4747" capable of being the phone number "8002624747"?

2) Assuming the data is valid, what is the internal format of that data? For example "(800)262-4747" becomes "8002624747". This is ICONV.

And in Arev CONV had to answer one:

1) What is the external format of the data? For example "8002624747" becomes "(800) 262-4747". This is OCONV.

—

… and here is a post I made to Steve Carlson:

What it sounds like you want is a validation pattern of MD0 that tests for a limit of 9999 (4 digits) with an iconv/oconv that both fmt R(0)#4. For example:

<code>
subroutine Num_Fmt(Conversion, InData, Branch, OutData)

$insert Logical

equ VALID$         to 0    ;* Successful
equ INVALID_MSG$   to 1    ;* Bad Data       -   Print error message window
equ INVALID_CONV$  to 2    ;* Bad Conversion -          "         "
equ INVALID_NOMSG$ to 3    ;* Bad but do not print the error message window

* determine desired length of formatted data
if assigned(Branch) else
  Branch="
end
if len(Branch) and num(Branch) then
  Length=Branch
end else
  Length=4
end

begin case
  case Conversion=ICONV"
    OutData ="
    Status()=VALID$

    begin case
      case len(InData)=0
        null
      case len(InData) ] Length
        Status()=INVALID_MSG$
      case OTHERWISE$
        Test=InData
        convert "0123456789" to "" in Test
        if len(Test) then
         * data had non-numeric characters
          Status()=INVALID_MSG$
        end else
          OutData=(str("0", Length): InData) -Length,Length
        end
    end case

  case Conversion=OCONV"
   * should already be ICONV'd so no data validation checking
    Status()=VALID$
    if len(InData) then
      OutData=(str("0", Length): InData) -Length,Length
    end else
      OutData="
    end

  case OTHERWISE$
    Status()=INVALID_MSG$
end case

return

</code>

To use this, put NUM_FMT,x on each field you want to work this way. (Replace the x with the number of desired digits. The conversion assumes 4 if you don't specify one.)

Arev didn't work this way. Arev templates had iconv and oconv, and iconv doubled for input validation. OI has validation and conversion, and conversion doubles for both iconv and oconv. Both ways work great if you understand what's going on.

—

I know this is a little redundant with what you posted, but I thought there might be something additional in it.

Cameron Purdy

Revelation Software

Cameron,

It was redundant, but it still firms my understanding

I suppose, then, my question is this: Are we expected to re-write our AREV oriented UDC's since OI implements them differently? I guess this is what has me confused, that is, the assumption that existing UDC's (sans UI specific logic) should work exactly as they did before. Were PHONE_FORMAT and ZIP_FORMAT rewritten?

Thanks,

[email protected]

SRP Computer Solutions

View this thread on the Works forum...