<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br><br>Right, I participated in that thread, but it was left without solution. Danil Osipchuk did a great work digging in the vm sources, and it seemed that vm was about to be ready to handle dead keys but not finished.<br>
The last email of the thread was this: <a href="http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-January/124248.html" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-January/124248.html</a><br>
<br>
So it seems the vm returns two different codes when pressing accents, what does not make sense and is not understood by the image.</blockquote><div><br>Here is a short summary. Recent VMs (mac, unix and windows) all have two fields in the event buffer where they store the keycode - 3th ("old") and 6th - ("new"-unicode). Behaviour though is not consistent - I think linux VM has bugs with the 6th field for navigation keys - left,right,down,up arrows and home/end. They seem to be just plainly wrong. Also when a character outside of ascii region is pressed - 3rd field contains 0. So you need to use both fields in InputInterpeter ( here is the linux version of InputInterpeter for Russian):<br>
<br>keyCode: sensor firstEvt: evtBuf<br><br> | keyCode |<br> keyCode := evtBuf third.<br> "trust the old field if it is control code - a workaround for inconsistency in unix VM, where evt sixth is wrong for movement arrows, home and end "<br>
(keyCode > 0 and: [keyCode < 16r21]) ifTrue: [^keyCode].<br><br> "otherwise rely on the ucs field"<br> ^evtBuf sixth.<br><br>Now for windows, it gives you always correct keycodes in the 6th field for ascii region, unicode and movement keystrokes (at least for Russian). When symbol is outside of the ascii range - 3th fied contains something unrelated with the ascii code < 128 - old implementation for Win1251 locale has been broken therefore too. But we don't care if we have can use 6th field. Unfortunetely mouse wheel movement stores zero there - and again you have to look at the 3rd field. <br>
<br>So, here is input interpreter for Russian on windows:<br><br>keyCode: sensor firstEvt: evtBuf<br> <br> " when mouse wheel is rolling the sixth field is not filled - return the third field instead"<br>
evtBuf sixth = 0 ifTrue: [^evtBuf third].<br> "otherwise use the ucs field strictly"<br> ^evtBuf sixth.<br><br>The logic of analyzing two fields is incompatible between windows and linux - hence to input interpreters.<br>
<br>Now about accents. If my guess is right and one can distinguish between accent modifiers and chars which are being modified - one can build up a custom InputInterpeter for, lets say Spanish, and I may try to do this. Two questions though - <br>
1) is it supposed by design that deadkeys are handled on the smalltalk side?<br> 2) is the information about dead keys available *somewhere* in the event buffer ( because last time when I checked if I pressed deadkey modifier the 6th field was zeroed on linux, and I forgot to check the 3rd). I also have not tried accented characters on windows yet. <br>
<br>cheers,<br><br> Danil<br><br><br><br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">No more progress since then.<br><br>Regards.<br>
José L.<br>
<br><br><br></blockquote></div><br>