Das deutsche QBasic- und FreeBASIC-Forum

[braesident]

Hallo liebe Leute

Ich habe mir aus der Bsp.Datei DrawStr.bas welche dem FB Paket beiliegt eine schöne Draw String Routine gebastelt. Die auch sehr gut läuft. Nun stört mich nur noch das halt kein € gezeichnet wird. In der Bsp.Datei gibt es ja folgende Sub

[Muttonhead]

dieser Abschnitt ist fürs Rendern zuständig

dort sind die Ecken wo du ansetzen müsstest:

[braesident]

danke, das war Rettung in letzter Sekunde. War gerade dabei FreeImage einzubinden. Hab schon die dll dateien in meine Ordner gepackt.

ich hab das jetzt erstmal mit IIF gelöst. Da die Tasten AltGr + E den Code 128 zurück geben, hab ich die Zeile nach deinem Tipp so geändert.

[St_W]

[braesident]

Hm Ok mit IIF hat es gut funktioniert wenn im Quelltext eine zeichenkette vorgegeben ist, die ein EUROzeichen enthält.
Leider ist es wie St_W schon gesagt hat bei tastureingabe nicht mehr so einfach. Und ich glaub das Problem ist, das nicht nur € sondern auch ? bei Inkey den Wert 63 zurück gibt.

Hab ihr da vllt. eine Lösung wie das €zeichen abgefragt werden kann und das natürlich ohne das Fragezeichen zu verlieren. Und am besten wär es wenn sich dies über den Quellcode bewerkstelligen ließe. Wäre schon blöd wenn man vom Benutzer verlangen müsste etwas am System zu verändern.

[Muttonhead]

vielleicht hilft Multikey() weiter.
Ich weiß nicht wie deine Eingaberoutine aussieht, aber vielleicht kannst du bevor du Inkey aufrufst mit multikey den Zustand der Tasten altgr und e abfragen und gegebenenfalls den Code fürs Eurozeichen an die Bibliothek senden.
Kann mich da an ein Thread erinnern von TimesChange, irgendwas mit qbasic konvertierungen..., jedenfalls wurde dort versucht die komplette Usereingabe via Multikey zu lösen, da auch alt und strg abgefragt werden mußten

Mutton

[braesident]

vielen Dank

war nicht ganz einfach diese Geburt
Ich habe erst immer Inkey und Multikey getrennt abgefragt

[Jojo]

1) Multikey solltest du nicht mit Inkey vermischen. Du solltest warten, bis genau diese drei Tasten nicht mehr gedrückt werden, und nicht mit Inkey auf leere Eingabe prüfen.
2) Mit dieser Multikey-Methode schließt du alle Benutzer aus, die kein deutsches Tastatur-Layout verwenden, oder zumindest ein Layout, bei dem man das Euro-Zeichen genau so eingibt - und es gibt genug Keyboard-Layouts, wo man das anders eingibt. Mit Inkey hat man da ein paar weniger Probleme, weil da die Tastendrücke bereits vom System in die richtigen Zeichen übersetzt werden.
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.

[braesident]

@ Jojo, ich kann dir da gerade nicht so ganz folgen. Du sagst multikey und inkey sollte ich nicht vermischen. Aber in der Referenz steht es doch genau andersherum.

[nemored]

MULTIKEY arbeitet halt anders als INKEY, und wenn du INKEY länger nicht abfragst, wird es von den MULTIKEY-Werten abweichen. Der Hinweis in der Referenz bedeutet lediglich, dass nach einer MULTIKEY-Abfrage die Tasten noch im Tastaturpuffer liegen; wenn du also auf neue Pufferwerte zugreifen will, muss man den Puffer vorher leeren. Die Verwendung von INKEY steht im Referenztext im deutlichen Zusammenhang mit dem Leeren des Puffers und ist keine Aufforderung, beides zusammen als Abfragemöglichkeit zu nutzen.

Wenn ich die Eurotaste per INkEY abfrage, bekomme ich gleich drei Werte, nämlich die Bytes des UTF8-Wertes. Interessant, dass die Betriebssysteme da verschieden arbeiten. Es wäre vielleicht zu überlegen, dem Benutzer für unbedingt erforderliiche Nicht-ASCII-Zeichen eine besondere Eingabemöglichkeit gegeben wird, vielleicht über Funktionstasten (was dann natürlich im Programm deutlich vermerkt werden müsste) oder grafisch über ein Button.
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1.

[braesident]

hilf mir bitte auf die sprünge. So langsam seh ich gar nicht mehr durch. Wie fragst du die Bytes des UTF8-Wertes per inkey ab?

[nemored]

Das wird dir nicht viel bringen.

[St_W]

Das Verhalten wundert mich etwas. Ich würde es eher als "Bug" bezeichnen. Denn Inkey sollte laut Doku eigentlich immer einen 1-Byte ASCII Wert oder einen 2-Byte Extended Keycode zurückgeben. Insbesondere ist es auch seltsam, dass drei einzelne Tastendrücke erkannt werden (zumindest deinem Code nach, wenn du den beschriebenen Output erhältst).


Das Input-Handling von FB ist leider sehr stark von QBasic beeinflusst und trägt daher viele Altlasten mit. Obwohl es nun insgesamt 3 Wege gibt, Tastatureingaben abzufragen (Inkey, Multikey, Screenevent) ist keine davon wirklich optimal.

Ich fände z.B. ein Inkey, das etwa die per WM_CHAR / ReadConsoleInput() erhaltenen Zeichen als Unicode zurückgibt ser sinnvoll. Der Unicode Support von FB ist allerdings immer noch sehr bescheiden bzw. großteils eher praktisch nicht vorhanden.
_________________
Aktuelle FreeBasic Builds, Projekte, Code-Snippets unter http://users.freebasic-portal.de/stw/
http://www.mv-lacken.at Musikverein Lacken (MV Lacken)

[braesident]

@ nemored
Ja stimmt, bei mir ist es nur 63 ( bei AltGr+e und bei ß/? )

Hab noch was interessantes hier im Forum gefunden.
Leider gab es kein weiteres Feedback dazu ob das Allgemeintauglich ist. Aber wenn dann müsste sich daraus eigendlich eine ziehmlich gute Eingaberoutine machen lassen. Wie der Autor aber schon gesagt hat müsste dabei halt noch der Programmfocus beachtet werden. Die enthaltene TestSub lief bei mir schonmal gut. (Win7 mit Netbooktastaur und deutschem Layout)

[St_W]

[nemored]

[nemored]

Nachtrag: Um meine Vermutung zu überprüfen, habe ich das obige Programm in der Konsole ausgeführt, nachdem ich mit