I am new to OI, from AREV. I am trying to convert an AREV app to OI. On the AREV App form I have several prompts where the user enters a number that must pass a validation test but which after passing the validation, the display of that data is intentionally foramtted not dispaly everything that was typed in. Using a phone number as a model in OI, here is what I want to do:

enter a 10 digit phone number say 333-444-7890

If it passes the validation have it displayed on the phone field as

(333) 444-7* Now using the the supplied PHONE_FORMAT conversion and changing the format in the oconv section to L(###) ###-#*

makes it display correctly. But of course when the record is saved

(333) 444-7* does not pass the validation check, and therefore we have a error. This of course worked correctly in AREV because the data was stored in @record in internal format and in OI, OI reads the properties of the controls before saving, so, of course (333) 444-7* which is displayed is not a correct format (and in fact at this point what the user typed in is lost).

I have read a great deal of the knowledge base ( many hours) worth and have experimented a great deal another many hours worth, I can not find a simple solution. Needless to say this is very frustrating. Can any help? I know if must be simple and I can not beleive I am the first to need this.

Thank you

Ed,

For all I know it's possible to write a UDC function to do what you want to do. I haven't got the knowledge to be able to tell you. (I did write what I felt was a pretty advanced UDC once, but I haven't kept up my knowledge on the subject.)

But let me try and attack the problem from scratch.

You have two versions of your telephone numbers. One is the real value. That is the one you want to store. The other is a display version, with the last digits hidden.

Who are the two versions intended for? I would think the two versions are intended for different types of users. There's no point in keeping digits secret from the ones doing data entry, so they can use the true version. Actually they'd be more prone to make errors if they can't see the true version all the time. And the users that aren't allowed to see all the digits might not be allowed to do data entry either. For them use a symbolic field with the masked version.

Or is the problem that both kinds of users use the same windows?

Or is the problem that the same person might be both kinds of user, i.e, allowed to know some telephone numbers in full, but not all telephone numbers?

I might be able to think of symbolic-based solutions for those cases also.

- Oystein -

Thank you for your response. Actually writing the UDC is the easy part and it worked great in AREV. The problem as I understand it is the basic fundelmental difference between the way AREV handled the data and the way OI handles it in thatwhenthe record is saved OI scans the controls for the data. AREV always maintained the data in @RECORD and really could care less what actually on the screen. You in fact have a user enter a number and display to the screen "I have a number". The orginal number was always maintained by the system. Again as I understand it not in OI. Unless I manually track the informtion all OI will see at save time is "I have a number" which of course is not what the user sees. In most cases the users have the same clearance but not when data is retrieved for display or editting. Here is a several examples: either credit card numbers or SSN numbers:

I enter the original credit card number for an order. Later the person calls back. All I can see is the last 4 digits of the credit card. If I need to change it I will reenter it from what the client tells me. If another operator calls up the record - again theyu can not see the entire number but the last 4 digits. If that operator needs to change it, they to reenter the whole number form what the client tells them. But operators in general whould never have access to the whole number once they press the "enter" key for that control.

Same scenerio for the SSN.

I think having different formsusing symbolics woudl be very cumbersome. This was soooo simple in AREV.

I am just not real sure the best way to handle these types of scernios in OI. One way is that I create "collector" windows and handle the whole thing myself, but I would think there should be an easier way.

IS there some way I can stuff information to the record in a Prewrite routine? If so where do Istuff it? I have been experimenting with that but have been unable to do it yet.

Actully this is the single biggest stumbling block to me converting my apps.

Ed,

Here's a suggestion.

Why don't you create a hidden control. This is databound and is where your SSN or whatever number is REALLY stored. Call this Real_Phone for example.

The control that you enter your number is really not a field at all. It's purpose is to display the number OR be used to enter the number. Call this Display_Phone.

At the Lostfocus of Display_Phone, you copy the "real" data to Real_Phone. Thus when you do a write, the real phone gets written.

Of course at the Read Event of the record, just copy the data found in Real_Phone into Display_Phone (with your formatting). You could also make Display_Phone a real field, but you may have to create a new dictionary item (that would be easy.)

Hth. Maybe someone has a more elegant solution.

Ray Chan

Ed,

I had a look at your conversion issue. My first grab is that you are right wrt differences in logic Arev v OI. As I see it there needs to be a 1:1 relationship on the conversion - it has to be bi-directional.

However you are looking for a security mask. Interestingly the original OI developers recognised this as an issue for passwords and implimented an editline mask specifically to do work round the bi-directional problem.

One way would be to make use of a temp variable - either global or tied to control (thereby handling the display much the way you did using @Record). I think this might be messy.

An alternate way, because you are using it as a security isssue across the application based on user security access, is to do it as a MFS. This should work fine.

Richard Bright

Richard and Ray,

Thanks for your suggestions. I will explore them further. It has given me some other ideas as well to explore.

View this thread on the forum...