hb_setTermCP() will mess up the keyboard input for national
chars when used in UNICODE builds, while it won't for non-UNICODE
builds. Tested with GTWVT.
The point here is not the "mess up" part, but rather that
app behavior is different in UNICODE and non-UNICODE builds.
This is most probably not right this way. (the culprit is
hb_setKeyCP() behavior)
I do not understand what is the problem in your case but for sure
above does not discribe GTWVT behvior.
For both UNICODE and non UNICODE modes all you should use:
hb_setTermCP( <cTermCP>, <cHostCP> )
where <cTermCP> is OS encoding and <cHostCP> is HVM encoding.
When <cHostCP> is not given then _SET_CODEPAGE is used.
The only one difference between UNICODE and non UNICODE mode
is the fact that in UNICODE mode <cTermCP> is ignored and only
<cHostCP> is significant but for user code it does not create
any differences.
Yes, sorry, I mixed the cases, it's ignored in UNICODE and
not ignored in UNICODE as you say.
It means I have to manually adjust CP setup for each platform,
build type and active GT (even WINE, but that's probably not
Harbour's fault). GTWIN works differently than GTWVT,
GTWVT works differently in UNICODE and non-UNICODE mode, and
things work a little bit differently with other GTs. Things
will be a bit more complicated on Windows, after my app switched
to ISO CP from DOS.
Now I had to drop hb_setTermCP() as it seems dangerous in
portable code. Instead I'm adjusting DispCP and KeyCP separately
depending on above factors. KeyCP is only set on *nix systems.
Plus HB_GTI_CODEPAGE on win when ISO CP is used. I didn't
test UNICODE mode in this scenario yet.
For me this is a little confusing. Prone to break easily.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
