[Allegro] Re: <Alt>+m-Mechanismus nicht invariant gegen'fcharset...' in spchr.rtf?

[Heinrich Allers]

T. Berger schrieb:

> Da a99 mit 8bit-Zeichensatz arbeitet, regiert entweder die fuer
> den Rechner eingestellte Standardcodepage (typischerweise CP 1252)
> oder CP 1252.
> 
> Da Windows intern mit Unicode arbeitet, weiss es ganz genau dass
> ein L mit Stroke, auch wenn es in irgendeiner anderen 8bit-Codepage
> notierbar ist, das Unicode-Zeichen U0141 *ist* und daher in
> CP1252 nicht abbildbar ist.
> ...

Windows weiß aber in dem Augenblick, in dem der Zwischenspeicher 
gefüllt wird, nicht, in welchem Zielfenster (unter welchem dort 
regierenden Font) er wieder ausgeschüttet werden soll! In der Tat 
kommt das L mit Stroke ja auch korrekt in einer Word-Textdatei an.

Die vom Kollegen Wolf beschriebene Situation, die dadurch 
ausgezeichnet ist, daß in einer Allegro-Datenbank durchgängig "Arial 
Unicode MS" mit charset=238 regiert, läßt sich in der Demo-Datenbank 
leicht nachbilden, indem man über "Option / Datenfont" einstellt auf 
"Arial Unicode MS / Skript: Mitteleuropäisch". (Ob das geklappt hat, 
sieht man nach Verlassen von Allegro datan, daß am Ende der INI-Datei

# letzte Schriftart in Listenfenstern:
DataFont=Arial Unicode MS
...
CharSet=238

steht.)

Unter dieser Voraussetzung ist U0141 (L mit Stroke) im Schreibfeld 
durchaus abbildbar, was damit zu belegen ist, daß es mit <Alt>+0163 
eingebbar ist.

Das müßte Windows wissen, wenn man seinen Zwischenspeicher mit dem 
Byte (hexadez.) A3 befüllt, und umso unverständlicher ist es deshalb, 
daß es den Inhalt seines Zwischenspeichers nicht im Schreibfeld 
ordentlich abliefert. 


Mit besten Grüßen von

Heinrich Allers
-- 
allers at t-online.de * http://www.h-allers.de
Netztagebuch: http://heinrich-erlo-ger.blogspot.com/
Bitácora: http://heinrich-erlo-spa.blogspot.com/