Hi all,

Do Editline and Editbox controls handle delimiters differently now?

We've used hidden Editlines extensively to hold the data in notes columns of Edittables, and then avoid the Edittable limit of 999 characters per cell. Whenever the user edits a cell in the notes column of one of these edittables, a zoom window opens to show the appropriate value stored in the hidden Editline.

In OI32 this no longer works. The hidden editline now seems to truncate our data to the first value. It doesn't seem to be a Unicode problem, as the same happens when logging into OI using the /ANSI switch. @tm seems to be a problem in editlines as well.

We've used this technique in many areas of the application for different purposes, so we'd be glad to hear of any easy way to avoid this.

Thanks,

Paul

Paul,

Do you know if OI 4.0 handled this the way OI16 did?

If you could put together a tiny little sample form that demonstrates the problem, package it up into an RDK, and send it to RTI, then there is a MUCH higher chance of this being addressed.

Thanks,

Pat

Thanks Pat.

This is different to how OI16 handled it. I'll make up a sample app today and send it through.

Cheers,

Paul

I built the sample and found I didn't have the problem any more!

It ends up that it is caused by our app setting CHARMAP.

/ansi mode does work - Editboxes convert @vm and @svm to @tm, which I thought was a problem, but OI16 does the same.

So the answer is to use /ansi mode unless we want to do a full Unicode conversion. We're reluctant to do that just yet as it is hard to find all places in the app which may need changing, and we'd have to go through a data conversion for all sites.

It would be great if we could set the application to be ansi during logon.

Thanks,

Paul

Paul,

It would be great if we could set the application to be ansi during logon.

Hmm…this actually could be done…

In the meantime, the next version of 4.1 will have the default mode as ANSI and the UTF8/Unicode mode needs to be enabled via a /UTF8 command line switch. I think that should make the 4.1 upgrading process less painfull for existing applications.

Pat

It would be great if we could set the application to be ansi during logon. Hmm…this actually could be done…

Perhaps a SYSENV setting? Or how about a SYSTEM property? How early in the bootup process does OI need to make it's decision…or can this be triggered on and off on the fly?

dbakke@srpcs.com

SRP Computer Solutions, Inc.

That's awesome! It would suit us perfectly, as we don't have to get all of our users to change their shortcuts.

An option which we can change programmatically would be good in the longer term - I like the idea of a SYSTEM property.

Thanks for all your help.

Paul

Don,

Whether or not data is processed as ANSI or UTF8 is a global setting throughout the system and this is not likely to change.  In other words, to enable this setting per form or per volume/file is not going to happen.

But I think that with not too big of an effort I could make it so this setting can be triggered on or off on the fly.  Ideally this ability would be integrated with a setting somewhere.

Pat

Paul,

…I didn't have the problem any more! It ends up that it is caused by our app setting CHARMAP.

But we should be allowed to set CHARMAP. I'd be interested to know if there was something wrong with your CHARMAP, so it would have failed in earlier versions of OI too. Also - was it uni- or bi-directional?

- Oystein -

Pat,

Whether or not data is processed as ANSI or UTF8 is a global setting throughout the system and this is not likely to change. In other words, to enable this setting per form or per volume/file is not going to happen.

I never thought about having *that* much control…nor do I think it is necessarily desirable. Having a way of setting it universally using a programmatic swith or environmental flag is awesome.

Thanks,

dbakke@srpcs.com

SRP Computer Solutions, Inc.

View this thread on the forum...