Since upgrading to OI3.6.1 I have been having problems with the Form designer.

I have a table that consists of a numeric key (MD3) and an associated description field. I have an XREF index on the description field that is uses a quick event to look for the associated key.

The index displays the data correctly in the popup i.e.

123.456 description here

234.560 another description here …

but when one is selected, the internally formatted number is returned to the edit line in the window. i.e. 123456. The ICONV on the data then places 123456.000 in the edit line.

I have deleted the dictionary, recreated it, attached and deattached tables and volumes, removed and added the index… all to no avail.

I deleted the form and recreated it and during this process I noted that in the New Form dialog, when I select OpenInsight Tables as the data source, I get a list of files with a number of blank lines at the top of the list of available tables.

I have also detached all application tables, ran 'DEFINE_DATABASE', looked at the the *.DBT table, reattached the application tables and reran 'DEFINE_DATABASE'. There didn't appear to be any obvious garbage in the *.DBT and the problem remains.

Any suggestions on where to look next?

John C. Henry

J.C. Henry, Inc.

John,

How are you implementing the MD3 conversion? In the dictionary or in the control's properties on the form. You might just be able to set up that editline to do the MD3 as well. As far as the .DBT file is concerned, that shouldn't be a problem unless it is larger than 64k.

Check into those conversion/validation patterns and where you are using them. If you still can't get it to work, let me know what version of OI you are using and some details about the dictionary (how many columns, the length, how many key values, etc..) and I'll see if I can create and fix the problem on my end.

-Scott Revelation

Scott,

I've tried the ICONV/OCONV both using ] and setting them explictly in the form.

Dictionary:

Key: ICD9_CD, DECIMAL(18), width 10, Validation MD3, Conversion MD3

FIELD 1 ICD9_DESC, VARCHAR(65531), no conversions/validations

Thanks,

John

John,

This worked previous to 3.61 but is broken now?

BTW are you doing the indexlookup via quick-event? If so, what property are you returning the data into?

Cameron Purdy

Revelation Software

Cameron,

Problem is the same in 3.6. I have a quickevent index lookup that returns to @SELF, TEXT property. I had an event handler on the control that I removed and then put the quick event on. I have deleted the dictionary and the window and recreated both of them.

Scan_Rep doesn't find anything strange in the repository.

Thanks,

John

John,

I hope I am not asking redundant questions, but I haven't gotten a good feeling for exactly what changed to break it. Is the following correct:

You had a custom coded event handler that worked fine regarding conversions and displays etc. from an index lookup but when you replaced it with a quick-event, it stopped working.

If I am still way off, please help fill in the blanks. Thanks,

Cameron Purdy

Revelation Software

Cameron,

I originally designed the problem window with an event handler that did all of the lookups… and returned the TEXT property in the edit field. I first noticed the problem when I removed the event handler and used a quick event index lookup.

Yesterday, on a completely different system (OI 3.6.1), I created a new table with two fields:

Field 0, DECI_KEY, MD3, DECIMAL(15)

Field 1, DECI_DESC,VARCHAR(65534)

Added an XREF index to DECI_DESC, specifying all delimiters (VM,FM,','…)

Build a form for this table using all defaults. Add the index lookup quick event to the DECI_KEY edit line. Entered two data values '123.456' - 'TEST RECORD 1'

'234.567' - 'TEST RECORD 2'

The ICONV/OCONV in the key field works fine during entry/recall.

Perform an index lookup on the keyfield (OPTIONS event). The expected POPUP appears displaying the data correctly. When one of the items is selected from the popup, the ICONV'd data is entered in the TEXT property of the DECI_KEY edit line. i.e. 123456 or 234567. The problem is in both 3.6 and 3.6.1 and appears to be in the process of getting the returned value from the popup into the editline's TEXT property. Hope this explanation is little clearer.

Thanks

John

J.C. Henry, Inc.

John,

Thanks for that extra info, I'll throw together the same variables in a little experiment here as soon as I wrap up some things I've been working on this afternoon. I'll let you know my results and, if they are the same, any workarounds I find.

-Scott Revelation

View this thread on the Works forum...