Re: Code Page problem in SetWindowText
- From: PackAddict <PackAddict@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 10 Sep 2007 08:52:14 -0700
I probably described the problem wrong.
A better description might be that there are Asc and Chr function calls
throughout the code, not duplication of algorithms throughout the code.
Those Asc and Chr function calls cause problems when a Chinese code page is
set as the default language. Each time that we hit a hex value with no
corresponding Ascii value in the code page, we get the "?' returned.
Needless to say, that causes some significant discrepences when
encrypting/decrypting a string of data.
I figured that I was going to have to move to byte arrays, but thought I'd
take a stab in the dark at a solution that would allow me to just overrid the
code page.
"Joseph M. Newcomer" wrote:
Encryption should be independent of locale, so I'm curious how there could be a problem..
In addition, "algorithms peppered throughout" the code suggests that there are deeper
architectural problems, since in most cases there is exactly ONE instance of the
algorithm, in ONE place. They are probably written in terms of char*, which assumes a
NUL-terminated 8-bit character string, which makes them instantly obsolete. They should
be written in terms of counted byte strings, not character strings.
joe
On Fri, 7 Sep 2007 09:46:06 -0700, PackAddict <PackAddict@xxxxxxxxxxxxxxxxxxxxxxxxx>
wrote:
I'm struggling with a similar issue. I have encryption algorithms pepperedJoseph M. Newcomer [MVP]
throught some legacy code (some written in VB3). They don't work when a
regional code page that is Unicode based is selected.
Is there a way to override the system regional code page setting to force a
VB 6 application to use "English (United States)"?
"Tom Serface" wrote:
Yeah, I hadn't thought of that angle. Sometimes I get all focused on local
heap memory and forget about all the automatic stuff happening behind the
scenes. I can say with a degree of certainty that going to Unicode has
worked for us over the last few years. There was some initial shock in the
transition, but it wasn't difficult to work through. Now we just do
everything Unicode so it makes life easier all around.
Tom
"Giovanni Dicanio" <giovanni.dicanio@xxxxxxxxxx> wrote in message
news:eJ81NXB8HHA.3624@xxxxxxxxxxxxxxxxxxxxxxx
"Tom Serface" <tom.nospam@xxxxxxxxxxxxx> ha scritto nel messaggio
news:OIPsKEB8HHA.5212@xxxxxxxxxxxxxxxxxxxxxxx
That's a really good point. I hadn't thought of that before. So I guess
if you are moving strings in and out of controls a lot there could even
be a performance improvement using Unicode.
Hi Tom,
I completely agree with this analysis by David, at least on the (real)
operating systems like Win2K/XP/Vista, that are Unicode-native.
(Win9x "toys" are a different thing, maybe there ANSI is faster than
Unicode, because they are ANSI/MBCS-native, but the Win9x family is not
interesting for me.)
G
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
- Follow-Ups:
- Re: Code Page problem in SetWindowText
- From: Joseph M . Newcomer
- Re: Code Page problem in SetWindowText
- References:
- Code Page problem in SetWindowText
- From: Marco Hung
- Re: Code Page problem in SetWindowText
- From: Mihai N.
- Re: Code Page problem in SetWindowText
- From: Tom Serface
- Re: Code Page problem in SetWindowText
- From: David Ching
- Re: Code Page problem in SetWindowText
- From: Tom Serface
- Re: Code Page problem in SetWindowText
- From: Giovanni Dicanio
- Re: Code Page problem in SetWindowText
- From: Tom Serface
- Re: Code Page problem in SetWindowText
- From: Joseph M . Newcomer
- Code Page problem in SetWindowText
- Prev by Date: Service not responding in a timely fashion (error 1053)
- Next by Date: Re: MFC application textbox input overflow on Japanese Windows 2000
- Previous by thread: Re: Code Page problem in SetWindowText
- Next by thread: Re: Code Page problem in SetWindowText
- Index(es):
Relevant Pages
|