Hi folks,
Has someone experience with reading/writing/displaying text files from .NET that can be compatible with Progress without damaging text (codepage)?
Goal:
in Progress environment you set e.g. cpstream 850, cpinternal ISO8859-15. You produce some file with some special local characters. Then you need edit these files in .NET application (C#, VB.NET) make changes and write back so it can be handled in Progress without damaging text. Codpeages are not always fixed so there must some settings for that.
What i try:
in .NET there is class System.Text.Encoding that can be used for reading/writing files, and Font Charset Property (https://msdn.microsoft.com/en-us/library/cc194829.aspx) for displaying it. So when i use CP850 for reading/writing files (some kind of cpstream) and set font to ANSI_CHARSET (1252, some kind of cpinternal) results are not identical and compatible (we talk about special characters >= 127). Each combination of cpinternal and cpstream produce in Progress different output file with same text as input, so it looks in .NET there must be used maybe same approach with 2 encodings? But on windows are usually used fixed encoding for display e.g. 1252 (Western European) and only file stream codepages can be changed runtime.
Any ideas, solutions to get .NET and Progress codepages "compatible"? Thank you.
Can you translate everything through UTF-8, or even UTF-16?
I would thinking using UTF-? for a consistent “external” (files and streams; read: bytes instead of strings) should get you a long way there. UTF-8 is very compatible, near universal, and there are conversion tables for it, to/from many other code pages in .NET, ABL, and Java.
We ran into pretty much this same with Visual Designer in PDSOE. Visual designer use TCP socket between the AVM hosting the .NET stuff and the PDSOE java process, so any data that needs to go between the text editor and the .NET GUI has to be converted from strings/numbers to bytes.
.NET uses UTF-16BE internally, but supports both UTF-16LE and UTF-16BE; but in java everything is UTF-16LE internally for strings. We needed some transfer that could handle any file encoding supported by java for .cls files.
We ended up reading whatever format the editor claimed was the file encoding (usually that was ISO8859-1) to java strings, wrote that as UTF-16LE bytes on the wire, moved it over to the .NET side and read it back in, then converted the UTF-16LE bytes over to UTF-16BE .NET native encoded strings. VD also reverses this from .NET -> wire ->java.
The conversion tables in both java and .NET are quite good, and UTF-16 has conversion for lots and lots of other code pages in both .NET and java.
You can use UTF-8/UTF-16 for "transfer" because you design the process flow :-) My problem is that i can't influence the middle thing - "transfer". My text files are actually Progress sources. If was source primary written for CP850 - i must read it as CP850, convert it at the background to Unicode/UTF-8, display it on Windows GUI, make some changes, convert it again to CP850 and write back to file. Both sides Progress editor and my application doesn't need to know each other but must produce exact files with same codepage. Source codepage can vary so it must be some generic way.