Hi,<br><br><div class="gmail_quote">2009/8/27 Andreas Raab <span dir="ltr"><<a href="mailto:andreas.raab@gmx.de" target="_blank">andreas.raab@gmx.de</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Michal Perutka wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
many thanks. I have tried your code (sorry for the delay - I spent two weeks with my family but without my laptop ;) and it works for me (hurray! :-) with these modifications:<br>
</blockquote>
<br>
Very good.<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
/Character value: .../ (or /keyValue asCharacter/ in your version of the next method) doesn't work for characters with unicodes > 255 (e.g. "latin small letter s with caron" $¹ has unicode 353).<br>
</blockquote>
<br>
Actually, that was no mistake. I meant to use Character value: xxx since I want us to get away from the leading char stuff in Unicode. What happens when you use Character value: instead of Unicode value:? Does it blow up? Does it display incorrectly? Anything else?</blockquote>
<div><br> $? for every code > 255. For example Character value: 353 shows $?, Character leadingChar: 14 code: 353 shows $¹<br> </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>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
UnicodeInputInterpreter>>nextCharFrom: sensor firstEvt: evtBuf<br>
"Compose Unicode character sequences"<br>
| peekEvent keyValue composed |<br>
"Only try this if the first event is composable and is a character event"<br>
((Unicode isComposable: (keyValue := evtBuf *sixth*))<br>
and:[evtBuf fourth = EventKeyChar]) ifTrue:[ ... ].<br>
"XXXX: Fixme. We should put the skipped event back if we haven't consumed it."<br>
<br>
^ *Unicode* value: keyValue<br>
<br>
Why evtBuf sixth ? Some keys on a Czech keyboard give me possibility to type Czech characters with diacritical marks directly. Correct codes (unicodes, e.g. 353 for $¹) I've found in evtBuf at the sixth position, not at the third. And the sixth position seems to be Ok for all characters.<br>
</blockquote>
<br>
Yes, that's correct. Mistake on my part. Element three is the old MacRoman value; number six is the UTF32 code point.<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
And the last thing: When I run Squeak with an option - encoding UTF-8, I think the UnicodeInputInterpreter should be installed. Otherwise I have to do it manually (World primaryHand keyboardInterpreter: UnicodeInputInterpreter new)<br>
</blockquote>
<br>
Right. I really dislike it that the Unix VM still doesn't use Unicode by default (as the Windows and Mac VMs do). Perhaps I can convince Ian to change the default.</blockquote><div> <br>Today I tested UnicodeInputInterpreter on Win XP and it works as well as on Linux.<br>
<br>Cheers<br>Michal<br></div></div><br>