Hi all -

I am beginning to familiarize myself with the IDE for OI10 and I came across something that I wasn't able to find.

In 9.x, the System Editor had an option to toggle UTF8 character mode. We use this when we are hard-coding Spanish-language text, for example when printing an OIPI document, to preserve the accented characters that we receive for the translations.

These stored procs need to be edited, saved and compiled while in UTF8 character mode or the accented characters won't print correctly.

How is this accomplished in the OI10 IDE?

(Apologies if this is already covered somewhere on the forums - I did a quick search and didn't find anything).

TIA

Chip

Hi Chip,

I'm assuming we're talking about the original System Editor (not System Editor++)?

The original v9 system editor (DWB.EXE) was a separate executable and so could support an option to change the UTF8 mode because it was "outside" of the main OI (OINSIGHT.EXE) process. I.e. it is isolated and can be changed without affecting the rest of the system.

The v10 IDE is now an actual OI form - changing the UTF8 mode in the same way is _possible_ but not really "safe". The UTF8 mode can be changed "on-the-fly" but it can lead to data-integrity issues so I would advise against it unless you're careful and aware of the possible side effects. At the end of the day it is expected that if you need UTF8 capability then your application should be a UTF8 application.

However, back to your issue - some possible solutions of the top of my head…

1) Make your application UTF8 (I'm assuming it's ANSI?)

2) Don't hardcode strings in your programs - rather use records that can be edited in a UTF8 application and then read when necessary (this is what we do at Rev using the rti_Res2Str() function and a bunch of records in SYSENV).

3) Edit and compile your procs in a UTF8 application and then write a tool to bring them back into your actual app (not very slick I know but… )

Regards,

Carl Pates

Thanks Carl

Yes, System Editor (not ++)

At one point we set the application globally to UTF8 a n d i t w a s p a i n f u l l y s l o w to the point that it wasn't usable; I'm not sure if it would behave better in OI10; realistically, the only data we need to store/process in UTF8 mode would be for email or printed correspondence, some of this is relatively static but some of this is cut-and-pasted or entered by users manually and it's not a huge percentage of our use cases.

When we need to allow the text to be user-editable we do store the text as a record and retrieve the data from the record in the stored procedure when printing or emailing. How we handle it is that we set UTF8(1) when the form that is used to edit it is opened, then set UTF8(0) when it's closed - so this would be the 'on-the-fly' method; we've worked this way for quite some time (probably since 2011 since that was when I posted some questions here about UTF8) and haven't noticed any negative consequences.

Thanks for the tips - I'll coordinate with Bruce and we'll see how it would be best to handle this.

Hey Chip!

Carl has done a LOT of work on improving UTF8 speed, even adding specific operators for optimum efficiency. It's unlikely you'd notice much of a degradation at all these days!

The Sprezzatura Group

The Sprezzatura Blog

World leaders in all things RevSoft

View this thread on the Works forum...