Alt+xxx keystroke don't make it through to my RichEdit control

September 03rd, 2007 - 05:20 am ET by Serge Wautier | Report spam
Env.: VS2003 / MFC

Hi All,
I'm posting this RichEdit problem here since it's related to a feature
most-likely used in i18n/l10n contexts.

My localization tool features a RichEdit control to let people type in
translations. A user recently brought to my attention that Alt+xxxx key
combinations used to type characters not directly available on the keyboard
sucks badly (wording mine, not his!): The first time (iow first character)
you use it, it works fine. Then it no longer works until you restart the
app.

My RichEdit is a RichEdit50W (on computers that support it. Else the program
downgrades to RichEdit v2/3).
Nothing fancy. It doesn't make any character/key WM processing. It just let
people type, then read the contents.

I tried to repro the problem in a test test program (using the same code to
create the control), to no avail :-(

A few more things:
appTranslator is a Unicode app.
I tried to downgrade RichEdit version to 2/3 (RichEdit20W). It then behaves
differently (but still wrongly): The characters displayed are not the one
expected: Most often CJK chars but sometimes something else. Couldn't find
any numerical relation between number typed and generated code point.
I used Spy++ and TRACE messages to check the messages posted by Windows to
the control: Everything looks fine and is identical in apps that work (test
app + Wordpad) and appTranslator.

Does this ring a bell to anyone?

TIA,

Serge
http://www.apptranslator.com

(Of course to make things even worse, this stupid problem is blocking
purchase by a big company...)
email Follow the discussionReplies 13 repliesReplies Make a reply

Similar topics

Replies

#6 Serge Wautier
September 03rd, 2007 - 03:14 pm ET | Report spam
Oops! I went a little too fast for the xxxx<Alt+X> test : this one does
indeed work.
But I confirm the other methods such as Alt+xxx or Alt+xxxx don't work
(although they do in my small test program and in Wordpad on the same
computer).

"Michael S. Kaplan [MSFT]" wrote in message
news:
Did you highlight the four characters? It works okay for me when I do
that.


MichKa [Microsoft]
NLS Collation/Locale/Keyboard Technical Lead
Globalization Infrastructure, Fonts, and Tools
Blog: http://blogs.msdn.com/michkap

This posting is provided "AS IS" with
no warranties, and confers no rights.


"Serge Wautier" wrote in message
news:
Doesn't work either.
Neither does xxxx+<altX>.

Thanks anyway.

Serge.

"Bob Eaton" wrote in message
news:
Try typing the four (hex) digits first and *then* do Alt+X.

This seems to work fine on my XP Pro/SP1 system and in WordPad (which
uses RichEdit)

Bob




"Serge Wautier" wrote in message
news:
Env.: VS2003 / MFC

Hi All,
I'm posting this RichEdit problem here since it's related to a feature
most-likely used in i18n/l10n contexts.

My localization tool features a RichEdit control to let people type in
translations. A user recently brought to my attention that Alt+xxxx key
combinations used to type characters not directly available on the
keyboard sucks badly (wording mine, not his!): The first time (iow
first character) you use it, it works fine. Then it no longer works
until you restart the app.

My RichEdit is a RichEdit50W (on computers that support it. Else the
program downgrades to RichEdit v2/3).
Nothing fancy. It doesn't make any character/key WM processing. It just
let people type, then read the contents.

I tried to repro the problem in a test test program (using the same
code to create the control), to no avail :-(

A few more things:
appTranslator is a Unicode app.
I tried to downgrade RichEdit version to 2/3 (RichEdit20W). It then
behaves differently (but still wrongly): The characters displayed are
not the one expected: Most often CJK chars but sometimes something
else. Couldn't find any numerical relation between number typed and
generated code point.
I used Spy++ and TRACE messages to check the messages posted by Windows
to the control: Everything looks fine and is identical in apps that
work (test app + Wordpad) and appTranslator.

Does this ring a bell to anyone?

TIA,

Serge
http://www.apptranslator.com

(Of course to make things even worse, this stupid problem is blocking
purchase by a big company...)














Replies Reply to this message
#7 Michael S. Kaplan [MSFT]
September 03rd, 2007 - 04:31 pm ET | Report spam
You do have to use the number pad for those methods to work, but they should
not fail


MichKa [Microsoft]
NLS Collation/Locale/Keyboard Technical Lead
Globalization Infrastructure, Fonts, and Tools
Blog: http://blogs.msdn.com/michkap

This posting is provided "AS IS" with
no warranties, and confers no rights.



"Serge Wautier" wrote in message
news:%
Oops! I went a little too fast for the xxxx<Alt+X> test : this one does
indeed work.
But I confirm the other methods such as Alt+xxx or Alt+xxxx don't work
(although they do in my small test program and in Wordpad on the same
computer).

"Michael S. Kaplan [MSFT]" wrote in message
news:
Did you highlight the four characters? It works okay for me when I do
that.


MichKa [Microsoft]
NLS Collation/Locale/Keyboard Technical Lead
Globalization Infrastructure, Fonts, and Tools
Blog: http://blogs.msdn.com/michkap

This posting is provided "AS IS" with
no warranties, and confers no rights.


"Serge Wautier" wrote in message
news:
Doesn't work either.
Neither does xxxx+<altX>.

Thanks anyway.

Serge.

"Bob Eaton" wrote in message
news:
Try typing the four (hex) digits first and *then* do Alt+X.

This seems to work fine on my XP Pro/SP1 system and in WordPad (which
uses RichEdit)

Bob




"Serge Wautier" wrote in message
news:
Env.: VS2003 / MFC

Hi All,
I'm posting this RichEdit problem here since it's related to a feature
most-likely used in i18n/l10n contexts.

My localization tool features a RichEdit control to let people type in
translations. A user recently brought to my attention that Alt+xxxx
key combinations used to type characters not directly available on the
keyboard sucks badly (wording mine, not his!): The first time (iow
first character) you use it, it works fine. Then it no longer works
until you restart the app.

My RichEdit is a RichEdit50W (on computers that support it. Else the
program downgrades to RichEdit v2/3).
Nothing fancy. It doesn't make any character/key WM processing. It
just let people type, then read the contents.

I tried to repro the problem in a test test program (using the same
code to create the control), to no avail :-(

A few more things:
appTranslator is a Unicode app.
I tried to downgrade RichEdit version to 2/3 (RichEdit20W). It then
behaves differently (but still wrongly): The characters displayed are
not the one expected: Most often CJK chars but sometimes something
else. Couldn't find any numerical relation between number typed and
generated code point.
I used Spy++ and TRACE messages to check the messages posted by
Windows to the control: Everything looks fine and is identical in apps
that work (test app + Wordpad) and appTranslator.

Does this ring a bell to anyone?

TIA,

Serge
http://www.apptranslator.com

(Of course to make things even worse, this stupid problem is blocking
purchase by a big company...)


















Replies Reply to this message
#8 Norman Diamond
September 03rd, 2007 - 09:10 pm ET | Report spam
Since the problem occurs on your client's machine, I think that it would be
more useful to report your client's settings than yours.

One additional setting might be meaningful: the input language/locale
(related to the keyboard driver). If the application thinks it's running in
locale A but the keyboard driver is delivering keystrokes in locale B then
there might be a clue.

By the way I think that input on the numeric keypad "should not" be affected
by some kinds of operations, but "should not" is different from "proven not
to have bugs". Notice how input on the main part of the keyboard "should"
be affected: On a French keyboard you need to shift in order to input
digits, and in other languages that I've read about you must avoid shifting.
Anyone want to test if some driver screws up keypad input in French
Canadian?


"Serge Wautier" wrote in message
news:%
OS : XP Pro SP2 fully patched
Language = English (Other languages are added using MUI but the test
doesn't involve them)
CP Regional Options: User locale = French (Belgium). I suspect my client
has English US or English Canada.
System locale (aka Language for non unicode programs) is French (Belgium)
as well. Although I doubt this is relevant since my app is Unicode-based.
msftedit.dll is v 5.41.15.1514.

Serge.

"Norman Diamond" wrote in message
news:%
I doubt that I can help with your problem, but I think it would be better
if add a bit more information:

Which OS, what service pack, which language version (real vs.
English+MUI), what Control Panel settings, etc.?


"Serge Wautier" wrote in message
news:
Env.: VS2003 / MFC

Hi All,
I'm posting this RichEdit problem here since it's related to a feature
most-likely used in i18n/l10n contexts.

My localization tool features a RichEdit control to let people type in
translations. A user recently brought to my attention that Alt+xxxx key
combinations used to type characters not directly available on the
keyboard sucks badly (wording mine, not his!): The first time (iow first
character) you use it, it works fine. Then it no longer works until you
restart the app.

My RichEdit is a RichEdit50W (on computers that support it. Else the
program downgrades to RichEdit v2/3).
Nothing fancy. It doesn't make any character/key WM processing. It just
let people type, then read the contents.

I tried to repro the problem in a test test program (using the same code
to create the control), to no avail :-(

A few more things:
appTranslator is a Unicode app.
I tried to downgrade RichEdit version to 2/3 (RichEdit20W). It then
behaves differently (but still wrongly): The characters displayed are
not the one expected: Most often CJK chars but sometimes something else.
Couldn't find any numerical relation between number typed and generated
code point.
I used Spy++ and TRACE messages to check the messages posted by Windows
to the control: Everything looks fine and is identical in apps that work
(test app + Wordpad) and appTranslator.

Does this ring a bell to anyone?

TIA,

Serge
http://www.apptranslator.com

(Of course to make things even worse, this stupid problem is blocking
purchase by a big company...)










Replies Reply to this message
#9 Serge Wautier
September 04th, 2007 - 04:17 am ET | Report spam
I do indeed use the numpad.
There's something really strange in there...

"Michael S. Kaplan [MSFT]" wrote in message
news:
You do have to use the number pad for those methods to work, but they
should not fail


MichKa [Microsoft]
NLS Collation/Locale/Keyboard Technical Lead
Globalization Infrastructure, Fonts, and Tools
Blog: http://blogs.msdn.com/michkap

This posting is provided "AS IS" with
no warranties, and confers no rights.



"Serge Wautier" wrote in message
news:%
Oops! I went a little too fast for the xxxx<Alt+X> test : this one does
indeed work.
But I confirm the other methods such as Alt+xxx or Alt+xxxx don't work
(although they do in my small test program and in Wordpad on the same
computer).

"Michael S. Kaplan [MSFT]" wrote in message
news:
Did you highlight the four characters? It works okay for me when I do
that.


MichKa [Microsoft]
NLS Collation/Locale/Keyboard Technical Lead
Globalization Infrastructure, Fonts, and Tools
Blog: http://blogs.msdn.com/michkap

This posting is provided "AS IS" with
no warranties, and confers no rights.


"Serge Wautier" wrote in message
news:
Doesn't work either.
Neither does xxxx+<altX>.

Thanks anyway.

Serge.

"Bob Eaton" wrote in message
news:
Try typing the four (hex) digits first and *then* do Alt+X.

This seems to work fine on my XP Pro/SP1 system and in WordPad (which
uses RichEdit)

Bob




"Serge Wautier" wrote in message
news:
Env.: VS2003 / MFC

Hi All,
I'm posting this RichEdit problem here since it's related to a
feature most-likely used in i18n/l10n contexts.

My localization tool features a RichEdit control to let people type
in translations. A user recently brought to my attention that
Alt+xxxx key combinations used to type characters not directly
available on the keyboard sucks badly (wording mine, not his!): The
first time (iow first character) you use it, it works fine. Then it
no longer works until you restart the app.

My RichEdit is a RichEdit50W (on computers that support it. Else the
program downgrades to RichEdit v2/3).
Nothing fancy. It doesn't make any character/key WM processing. It
just let people type, then read the contents.

I tried to repro the problem in a test test program (using the same
code to create the control), to no avail :-(

A few more things:
appTranslator is a Unicode app.
I tried to downgrade RichEdit version to 2/3 (RichEdit20W). It then
behaves differently (but still wrongly): The characters displayed are
not the one expected: Most often CJK chars but sometimes something
else. Couldn't find any numerical relation between number typed and
generated code point.
I used Spy++ and TRACE messages to check the messages posted by
Windows to the control: Everything looks fine and is identical in
apps that work (test app + Wordpad) and appTranslator.

Does this ring a bell to anyone?

TIA,

Serge
http://www.apptranslator.com

(Of course to make things even worse, this stupid problem is blocking
purchase by a big company...)






















Replies Reply to this message
#10 Serge Wautier
September 04th, 2007 - 04:24 am ET | Report spam
The problem happens on my machine as well.
Also, I use the numpad to key in the digits.
Last but not least, at the end of the sequence, Spy++ clearly shows a
"composite" WM_CHAR message being crafted and posted to the RichEdit
control. It is therefore not a keyboard problem.

"Norman Diamond" wrote in message
news:
Since the problem occurs on your client's machine, I think that it would
be more useful to report your client's settings than yours.

One additional setting might be meaningful: the input language/locale
(related to the keyboard driver). If the application thinks it's running
in locale A but the keyboard driver is delivering keystrokes in locale B
then there might be a clue.

By the way I think that input on the numeric keypad "should not" be
affected by some kinds of operations, but "should not" is different from
"proven not to have bugs". Notice how input on the main part of the
keyboard "should" be affected: On a French keyboard you need to shift in
order to input digits, and in other languages that I've read about you
must avoid shifting. Anyone want to test if some driver screws up keypad
input in French Canadian?


"Serge Wautier" wrote in message
news:%
OS : XP Pro SP2 fully patched
Language = English (Other languages are added using MUI but the test
doesn't involve them)
CP Regional Options: User locale = French (Belgium). I suspect my client
has English US or English Canada.
System locale (aka Language for non unicode programs) is French (Belgium)
as well. Although I doubt this is relevant since my app is Unicode-based.
msftedit.dll is v 5.41.15.1514.

Serge.

"Norman Diamond" wrote in message
news:%
I doubt that I can help with your problem, but I think it would be better
if add a bit more information:

Which OS, what service pack, which language version (real vs.
English+MUI), what Control Panel settings, etc.?


"Serge Wautier" wrote in message
news:
Env.: VS2003 / MFC

Hi All,
I'm posting this RichEdit problem here since it's related to a feature
most-likely used in i18n/l10n contexts.

My localization tool features a RichEdit control to let people type in
translations. A user recently brought to my attention that Alt+xxxx key
combinations used to type characters not directly available on the
keyboard sucks badly (wording mine, not his!): The first time (iow
first character) you use it, it works fine. Then it no longer works
until you restart the app.

My RichEdit is a RichEdit50W (on computers that support it. Else the
program downgrades to RichEdit v2/3).
Nothing fancy. It doesn't make any character/key WM processing. It just
let people type, then read the contents.

I tried to repro the problem in a test test program (using the same
code to create the control), to no avail :-(

A few more things:
appTranslator is a Unicode app.
I tried to downgrade RichEdit version to 2/3 (RichEdit20W). It then
behaves differently (but still wrongly): The characters displayed are
not the one expected: Most often CJK chars but sometimes something
else. Couldn't find any numerical relation between number typed and
generated code point.
I used Spy++ and TRACE messages to check the messages posted by Windows
to the control: Everything looks fine and is identical in apps that
work (test app + Wordpad) and appTranslator.

Does this ring a bell to anyone?

TIA,

Serge
http://www.apptranslator.com

(Of course to make things even worse, this stupid problem is blocking
purchase by a big company...)













Replies Reply to this message
Help Create a new topicNext page Previous pageReplies Make a reply
Search Make your own search