Mail Archives: djgpp/2000/01/18/17:12:57
Manni Heumann writes:
> (Pseudocode):
> char c=readkey() & 0xff;
> textprintf ("%c", c);
>
> all I get is garbage as soon as I press some Umlaut-key
Try printing out the value of c in decimal, and check that it really
is what www.unicode.org says should be that accented letter. If not,
there is something wrong with whatever keyboard mapping table you are
using: I'm afraid I don't have the time or enthusiasm to check all
these myself, but would be delighted to accept fixed versions if you
find problems with any of them (the individual mapping files can be
exported from keyboard.dat using the grabber, and edited using the
setup/keyconf utility).
If the value of c is correct, I'd be suspicious that your real code
doesn't quite look like the above psuedocode. The textprintf()
routine comes from Allegro, so is fully Unicode-aware, but this
would fail if you were actually calling sprintf() instead, because
that knows nothing about Unicode (you should use usprintf() instead),
or it would fail if you did something like "mystring[0] = c", since
it might require more than a single byte to store c (you should use
the usetc() or usetat() functions instead).
> Another problem I just discovered are tabs: In former versions (3.11)
> I could textprintf a tab with no trouble, but in 3.95 a '\t' will
> also come out as '^'. Is this a related problem?
Actually tabs have never been supported: Allegro doesn't know anything
about formatting characters. Older versions used to print all unknown
characters as spaces, while newer ones print them as squiggles. If
you need to output tabs you'll have to either write your own more
capable formatting code, or use something like the d_textbox_proc()
GUI object that does support such formatting, or you could bodge it
by including a tab character graphic in your font.
Shawn Hargreaves.
- Raw text -