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

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...)

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...)

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...)

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...)

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...)