Can I do ExternalValue=Oconv( InternalValue, "my_UDC")? Or is that beyond Oconv's capability?

- Oystein -

Yes, I do it all the time, assuming my_UDC is your conversion program

Simon

RebusHR

Simon,

Nice! Thanks! Where in BRFHELP is it docced? Not the OConv article. Not the Fmt article.

- Oystein -

Oystein ..

I believe it's in the Arev KB app and probably in the OI Workshop section too. Sprezz also has a nifty downloadable little thingie that accesses the KB. Since I use UDC ICONV/OCONV's all the time, both in AREV & OI, I just do it.

Don

Don,

Right.

Revelation - please include in new docs.

- Oystein -

Hi All

I am having a slight problem, that I am hacking around with an axe.

My form has date fields for which I have my own conversion routine ie

in the conv and validation bits of the date field properties I have

"TPM_CONV, DATE" - this routine allows dates to be returned in what ever format the client wants eg 2 digit years/4 digit years.

This form is not bound to a file/table.

Problem is, even when I have the field set to "required field", and the conv routine reports an error, the date field is being cleared, emptied and the cursor is moving to the next control instead of staying put.

So I am taking off all the conv stuff and the required field bit and making it work via a commuter event called from the quick event…

Is there something I missed or does this happen to other people's forms?

Scott, LMS

This is doced by way of example in SYSPROG –] PHONE_FORMAT

Suggest that you are very careful with any error messages - could have serious problems when running a report and data wrong!

Again, need to work thru use in specific situations such as EditTable - where you may be doing more than just display conversion. Only downside is that Btree.Index is of internal value.

Major advantage is to do away with code + Lookup value; just show Lookup value.

Note that you can establish generic UDC and use branches for specific implimentations eg Result=Oconv(InternalVal,'MY_UDC,Branch')

the Branch seems to work either inside or outside the ]'.

Like so many features of OI, the best ones are not well doced.

NB the alternative to UDC is MFS.

Richard Bright

BrightIdeas New Zealand

[email protected]

Richard,

This is doced by way of example in SYSPROG –] PHONE_FORMAT

Here's the documentation that I've found:

compile SUBROUTINE PHONE_FORMAT( charstr CONV, charstr ANS, charstr BRANCH, charstr RETURN_DATA)
*
*   PHONE_FORMAT is an example of a developer's custom prompt formatting
*   routine using the square brackets call.
*
*   It should be placed in square brackets, like this:
*
*                   PHONE_FORMAT
*
* This subroutine should be used as the first and only "Input Validation" in
* a window prompt.  Placed in "Output Format", it properly formats any
* reasonable string of numbers into a consistent US telephone number format.

I haven't found it mentioned anywhere it can be used in a programmatic OConv or IConv.

Suggest that you are very careful with any error messages

I know. So my UDC just tries to make the best out of every situation and never gives an error message.

My UDC handles a flexible date field. I made that UDC a long time ago. I discussed it on the list, and I believe you were among those who helped me. The UDC has worked very well. It's just that I never used it in a programmatic OConv call before, just in the dict and the validation/conversion settings for various edit controls.

Again, need to work thru use in specific situations such as EditTable - where you may be doing more than just display conversion.

Please elaborate.

Or perhaps not. My holiday starts very soon and I might not read your reply for some time.

Only downside is that Btree.Index is of internal value.

Doesn't really matter in my case, because neither the internal nor external value is suitable for indexing. I have to make a symbolic anyway and index that.

Major advantage is to do away with code + Lookup value; just show Lookup value.

That's a different kind of use from mine. My UDC is a bit more like PHONE_FORMAT and ZIP_FORMAT. In my case the advantages are that it

- allows the user some freedom in how he inputs data

- saves him a few keystrokes

- gets the value well and truly standardized before it's stored.

But I have some fields were I should consider the kind of use you suggest.

Note that you can establish generic UDC and use branches for specific implimentations eg Result=Oconv(InternalVal,'MY_UDC,Branch') the Branch seems to work either inside or outside the ]'.

Before I get me more than one single UDC using Branch is a bit heavy. But what about a different kind of use - tell the UDC if it's safe to issue a warning?

NB the alternative to UDC is MFS.

True. But it wouldn't work so well in my case because the users' input might be interpreted and stored differently from what he expects. I need to show how my programming interpreted it. As a very trivial example a year "3" might be interpreted as "2003" while he meant "1903".

- Oystein -

I will leave the issues od Edittable / UDC / postprocess stuff to another day. (Any way only has relevance where one is using it with a lookup table and wanting to add to the lookup table.)

Use of Branch - a simple example might be wher you have a generic date or measurement format routine and wanted to specify the output format ie

date - dd/mm/yy or dd/mm/yyyy — so use branch 2 or 4

meaurement 123.2345 or 123.23 — use branch 4 or 2

Just set the branch in the OConv / Iconv function.

Regards

Richard Bright

View this thread on the forum...