Hi John
I will accept that in my 50 years experience as a developer, IT Manager
and consultant I never had the need to use VB6. Therefore I was equally
puzzled by the limitations that the Legacy developers seem to have
applied, given that by the late 1990s Unicode support was becoming
common. So I did a web search for 'VB 6 Unicode' and found this website
at VBForums:
http://www.vbforums.com/showthread.php?365738-Classic-VB-Does-Visual-Basic-6-support-Unicode
Note that the initial entry, in 17 Jun 2008, explicitly refers to the
conversion of 16-bit characters (aka Unicode) to ANSI in API interfaces
and file saves. It then extends to discuss the development of Unicode
based API extensions and the use of code sets. There are then a number
of later posts regarding methods to implement Unicode in VB6.
If we believe this, and I have no reason not to, it would appear that
the Legacy developers were limited to the ANSI character set, unless
they were prepared to develop or acquire Unicode based APIs and
interfaces.
This has been an issue with Legacy for many years and even the Legacy
support staff agree that they are limited to ANSI.
___
Hi Otto
I am running the latest version of Legacy, 9.0.0.332, on a 64-bit Win 10
system using the English (United Kingdom) display language - which
version are you running with.
If I create a new person and enter into his name fields via the Alt+9999
sequence in the range Alt+0032 to Alt+0255 then Legacy will accept then
into the field on the display, excluding later checks that Legacy might
want to apply if I Save the record. However, if I continue with
Alt+0256, Alt+0257 .... onwards, then the additional characters are not
included in the fields, and usually respond with a beep. Hence, those
fields are limited to the ANSI character set.
Equally, if I create a new event and then type into the Notes field,
then I can happily ENTER additional characters, thus I can ENTER and
have DISPLAYED the following,
Alt-0250 to Alt-0255 : úûüýþÿ - this is the Unicode set for u with
Acute, Circumfles and Diaeresis, y with Acute, lower case Thorn and y
with Diaeresis
Alt-0256 onwards, using Copy from Character map : ĀāĂ㥹ĆćĈĉĊċČč - some
of these do not work using the Alt-9999 format, these are the upper and
lower case pairs of A with Macron, Breve and Ogonek, and C with Acute,
Circumflex, Dot Above and Caron.
So, text fields will accept, as input, characters past the ANSI set,
while control fields will not, or will convert them to ?. That is good
UNTIL you want to save the data. Do that and then open the event - ALL
of the characters after Alt-0255 are missing, so it will ONLY save
within the ANSI set.
Also, if you refer to the Special Character set, click on the solid
square at the top of the bar to the left of the Notes field in the
Event, and you will see a list of the characters that Legacy will accept
- this should be a match to the Alt-0032 to Alt-0256 set from the
Windows Character Map. As far as I can tell it does, but my version of
Char Map misses U+007F through U+009F if set to Unicode, and does show
them if set to Windows:Western with exceptions.
This points us to the question of code sets, which were designed in the
1980s to enable different glyphs to be used for characters in the
Alt-0128 to Alt-0255 range to be used to cover multiple alphabets using
the same character code to represent different glyphs. Good, so long as
you only work within a single code set, and difficult if not unless you
can deal with changing the code set on the fly. Of course, Unicode was
the solution for that, enabling the extension of the character set from
8-bits to 16- and 32-bits, so long as the programmer KNEW which version
was in use - there were multiple versions in the early days.
Now, Otto, I see from your response below that you seem to be based in
Finland. If I convert my Character Map to show the Windows:Central
Europe set I can see that the character set for the range from Alt-0128
onwards is different, and includes the C with Acute, Cedilla and Caron
marks. Within the Western set only the version with Cedilla is present -
C with Acute becomes the Æ glyph ( a combined AE glyph) and the C with
Caron becomes the È glyph (E with Grave). In Unicode all of the C with
Acute, Circumflex, Dot Above and Caron glyphs are in the range U+0106 to
U+010D and outside of the ANSI set within a Western code set.
___
All of this indicates that Legacy was developed in the 1990s, within
America, with the traditional mindset of ANSI and the Western Europe
code set, and perhaps supports different code sets if you change the
default language set, and has never been extended to support Unicode.
Regards
Chris
------ Original Message ------
From: "Otso Havu" <otso.h...@gmail.com>
To: "Legacy User Group" <legacyusergroup@legacyusers.com>
Sent: 27/11/2019 01:00:15
Subject: Re: [LegacyUG] Using special alphabet characters in Legacy
Legacy accepts Unicode from Win CharMap eg. in the Notes field, i just tried
ke 27. marrask. 2019 klo 1.48 John Cardinal (jfcardi...@gmail.com) kirjoitti:
Chris Hill wrote:
> NO, the issue is that native VB6 only uses API interfaces
> that are limited to ANSI.
Chris,
That's not true. I've built a dozen or so commercial programs in VB6 that
read/write/manipulate Unicode data, including reading and writing UTF-8 files,
presenting data entry screens, running reports, etc. A few are still being
used. Perhaps there are old third-party components that are not Unicode-aware,
but VB6 was certainly not limited to ANSI, API or otherwise. VB^ used in MS
Access? I have only done some light scripting there so I don't know what issue
Unicode may have presented there.
The string type in VB6 used "wide" characters (as they were called then), 16-bits each. It's true that one
had to be careful when calling Windows APIs directly and call the correct "W" methods. Calling Windows APIs
directly was probably less than 15% of the code in my applications. To write a UTF-8 file, one had to use the
"binary" version of the Open File statement ("Open FileSpec For Binary Access Write …") and then
convert the chars to UTF-8 before using the PUT call to write the text, but any reasonably-accomplished VB6 programmer
knew how to do that. The details escape me, but using binary I/O may only have been necessary when low-level control
was required, such as reading/writing the Byte-Order-Mark (BOM).
Of course, VB6 was very easy to use and so there were a lot of junior-level
programmers who may have been flummoxed by working with Unicode, but that's not
the fault of VB6.
John
--
LegacyUserGroup mailing list
LegacyUserGroup@legacyusers.com
To manage your subscription and unsubscribe
http://legacyusers.com/mailman/listinfo/legacyusergroup_legacyusers.com
Archives at:
http://www.mail-archive.com/legacyusergroup@legacyusers.com/
--
Otso Havu +358 50 5534170 +358 50 408 2248
otso.havu..gmail.com
Sulkapolku 6 B 13
FI-00370 Helsinki
Finland
skype: otso.havu
--
LegacyUserGroup mailing list
LegacyUserGroup@legacyusers.com
To manage your subscription and unsubscribe
http://legacyusers.com/mailman/listinfo/legacyusergroup_legacyusers.com
Archives at:
http://www.mail-archive.com/legacyusergroup@legacyusers.com/
--
LegacyUserGroup mailing list
LegacyUserGroup@legacyusers.com
To manage your subscription and unsubscribe
http://legacyusers.com/mailman/listinfo/legacyusergroup_legacyusers.com
Archives at:
http://www.mail-archive.com/legacyusergroup@legacyusers.com/
