Back to WM_UNICHAR?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Back to WM_UNICHAR?

Chris Petsos
 
Remember at start that you 've been telling me to acquire unicode chars by handling the WM_UNICHAR message?
Well...i didn't and now i am having the first problems...
First...keyboard shortcuts do not work of course when i have the keyboard turned to my locale.
The charCode member of the event buffer takes values above 128...
We can interpret it back to MacRoman values inside the image but then the so called "unicode" environment will be polluted with locale specific code. Also, each environment can provide interpreters for itself without polluting the base UnicodeEnvironment class but still i don't know. Another, smaller, problem is that the mouse wheel does not work...and i don't know what else can come up in the future...
 
Do you think it would be wise to try once again handling WM_UNICHAR and leave everything else unchanged?
Documentation and reports on this message are really vague and controversial... some did it, some didn't ...i don't know! Any suggestions???
 
Christos.
Reply | Threaded
Open this post in threaded view
|

Re: Back to WM_UNICHAR?

Andreas.Raab
 
Interesting question. Yoshiki, how does the Nihongo image deal with
shortcuts? It should have the same problems given that Squeak shortcuts
are handled as (translated) keystrokes.

Cheers,
   - Andreas

Chris Petsos wrote:

>  
>
>
> ------------------------------------------------------------------------
>
> Remember at start that you 've been telling me to acquire unicode chars
> by handling the WM_UNICHAR message?
> Well...i didn't and now i am having the first problems...
> First...keyboard shortcuts do not work of course when i have the
> keyboard turned to my locale.
> The charCode member of the event buffer takes values above 128...
> We can interpret it back to MacRoman values inside the image but then
> the so called "unicode" environment will be polluted with locale
> specific code. Also, each environment can provide interpreters for
> itself without polluting the base UnicodeEnvironment class but still i
> don't know. Another, smaller, problem is that the mouse wheel does not
> work...and i don't know what else can come up in the future...
>  
> Do you think it would be wise to try once again handling WM_UNICHAR and
> leave everything else unchanged?
> Documentation and reports on this message are really vague and
> controversial... some did it, some didn't ...i don't know! Any
> suggestions???
>  
> Christos.
Reply | Threaded
Open this post in threaded view
|

Re: Back to WM_UNICHAR?

Chris Petsos
 
> Interesting question. Yoshiki, how does the Nihongo image deal with
> shortcuts? It should have the same problems given that Squeak shortcuts
> are handled as (translated) keystrokes.
>

This is what i came up with... i am thinking of translating the Unicode
chars to ANSI below 127 at the VM side before entering the image. I think it
can be done. Thus, the charCode deta member, the third member of evtBuf is
always going to have the correct ANSI values for the shortcuts and
everything, no matter what locale the keyboard is turned to.
I am working on it.

Christos

Reply | Threaded
Open this post in threaded view
|

Re: Back to WM_UNICHAR?

Yoshiki Ohshima
In reply to this post by Andreas.Raab
 
> Interesting question. Yoshiki, how does the Nihongo image deal with
> shortcuts? It should have the same problems given that Squeak shortcuts
> are handled as (translated) keystrokes.

  Sorry, I missed that.

  When the Windows IME is enabled, it have the VM generate KeyDown and
KeyUp events when the user hit a key, but not KeyChar.  At the same
time, it modifies the candidate buffer in the IME.  When the user
confirm that the candidate buffer is correct, the IME sends these
bytes (on older VM) or the unicode code points (new VM) to the VM with
as KeyChar.

  For short cut like Alt-a, the IME also passes the events to the VM
and VM generates KeyDown, KeyChar and KeyUp.  In this case, the
KeyChar event has Alt-bit set, so the Squeak can act properly.

  I finally got around testing the Japanese input with 3.10.4 VM and
by providing a simple "UTF32JPInputInterpreter", it works ok.

  And, clipboard works with a simple clipboard interpreter.

  I'll do a bit more test of corner cases, and makes up a change set.
Appearently, I have been holding back the world's progress, but we are
making good progress^^;
Reply | Threaded
Open this post in threaded view
|

Re: Back to WM_UNICHAR?

Andreas.Raab
 
Yoshiki Ohshima wrote:
>   For short cut like Alt-a, the IME also passes the events to the VM
> and VM generates KeyDown, KeyChar and KeyUp.  In this case, the
> KeyChar event has Alt-bit set, so the Squeak can act properly.

Ah, interesting. So the IME basically passes those events that it
doesn't translate straight through.

>   I finally got around testing the Japanese input with 3.10.4 VM and
> by providing a simple "UTF32JPInputInterpreter", it works ok.
>
>   And, clipboard works with a simple clipboard interpreter.

Good. Thanks for letting me know.

>   I'll do a bit more test of corner cases, and makes up a change set.
> Appearently, I have been holding back the world's progress, but we are
> making good progress^^;

Heh, heh. I think you're kinda working the world's progress with OLPC
anyway ;-)

Cheers,
   - Andreas