AutoHotkey Community

[DerRaphael]

Hallo,

für alle, die Bedarf haben mit Autohotkey Unicodezeichen darstellen zu müssen (wollen) und bisher daran scheiterten, dass AHK das nativ nicht kann: hier mal eine kleine Lösung, die zeigt wie sowas dennoch möglich ist.

Ein paar Beispielzeichen für Japanisch:
イントロダクション

Hier mal ein paar kyrillische Zeichen:
И дополнение на русском.

So sieht das dann Im Script aus:



Hier das Script:

[Thalon]

[haichen]

Ich habe ein paar Funktionen geschrieben, mit denen on the Fly die komplette Sprache einer Applikation ändern kann. Kann man schön mit Kronomium ausprobieren (funktioniert auch ohne CMOSTimer).
Menüs, Texte, ToolTips - alles was man als Variable nutzen kann. Die Texte hole ich mir dabei aus einer Ini-Datei oder aus einer Variable, die wie eine Ini-Datei aufgebaut ist. Dort steht dann zB.
Varirgendwas= Übersetzung

Ich überlege Dank Deines Beitrags ob ich meine Funktionen vielleicht erweitere.
Meine Frage ist, ob es wohl Sinn macht, die Übersetzungen in so einer ini-Datei zu speichern und wenn ja in welchem Format, als Bin oder als Hex?

Varirgendwas= fffef330c830ed30c030af30b730e730f330
Varirgendwas= ÿþ¤0ó0È0í0À0¯0·0ç0ó0

Und wenn Hex, wie gehts? Das bekomme ich leider nicht hin (trotz bin2hex() ).
Würde mich freuen Eure Meinung zu hören.

[derRaphael (nli)]

hallo haichen!

du solltest hex2bin verwenden (was du bestimmt meintest) lt PhiLho kann dann dieser binärtext an ein Element übermittelt werden, das eine hWnd hat.
wenn der text vorher als UTF-8 gespeichert wurde (autohotkey ignoriert ja die BOM) muss die Ini vorher darauf überprüft werden und eine interne UTF8 nach Unicode konvertierung stattfinden.

Wenn du also bei einem Menüeintrag etwas ändern möchtest, musst du genau diesen ansprechen können. das beispiel, was ich hier gebracht habe funktioniert mit Static Controls (da jene eine eigene hWnd haben)

mittlerweile habe ich herausgefunden, wieso es in win2000 nicht funktioniert. die einzelnen Controls scheinen jeweils mit CreateWindow statt mit CreateWindowW erstellt zu werden. Letzteres erlaubt Unicodezeichen. Ersteres nicht (zumindest bei älteren Versionen). Auf MSDN wurde explizit darauf hingewiesen. Im Augenblick arbeite ich an einer Lösung, die Unicodes innerhalb einer Listview erlaubt, jedoch wie es scheint müssen Änderungen an Autohotkeys Source gemacht werden oder alle Funktionen, die GUIs abbilden nachgebaut werden. (In der Source CreateWindowW, SendMessageW und PostMessageW zu verwenden erscheint mir einfacher als aller umzustricken, damit eigene Controls gebaut werden können, deren Syntax lediglich nur an Autohotkey angelehnt ist und nicht den Komfort der eingebauten funktionen bietet.

ich bleibe am ball!

es grüßt euch
derRaphael

[derRaphael (nli)]

[haichen]

Ja, das ist noch ein bißchen ein Buch mit sieben Siegeln.
Ich kann wohl dank dieser Funktionen einen binären oder hex Code anzeigen lassen, aber wie wandel ich zB. japanische Schriftzeichen in speicherbaren Text (hex oder bin ?) um. Das war wohl meine Frage.

[derRaphael (nli)]

[derRaphael (nli)]

[haichen]

Wunderbar.. genau so etwas hatte ich mir gedacht.

Vielen Dank
haichen

[haichen]

Hier mal eine kleine unicode version von langhelp. An der include Datei hat sich nichts geändert.
Includes:
BinaryEncodingDecoding von PhiLho
LangHelp von mir

Unicode Bsp:
langmini

In diesem Fall sind alle Texte in der Variablen IniVar vorgegeben. Wie man leicht erkennt kann man dies auch mit readfile machen. Die Menüs kann ich aber wohl noch nicht in unicode übersetzen oder haben die auch ein hwnd?

[derRaphael (nli)]

soweit ich weiß, haben einzelne menüelemente keine hwnd, da muß man anders herangehen, ähnlich wie bei ListView / TreeView / ComboBox / DDL
diese Elemente unterliegen einer weitern Struktur, die zwar änderbar ist, jedoch muss man den Aufbau der selbigen kennen. im einzelfall bedeutet es die AHK funktionen für jeden einzelfall nachzubauen. wie bereits geschrieben, an einer umsetzung für ListView Elemente bin ich bereits dran.

BTW: WindowsXP wurde ebenfalls getestet und funktioniert einwandfrei.

Für eine l10n Version von Software, muss diese also mindestens unter winXP laufen, da beispielsweise bei windows2000 die routinen für unicode zwar existieren, jedoch nicht von AHK nativ verwendet werden. bei winxp und jünger biegt das betriebssystem entsprechende anfragen um (oder ist gleich unicode fähig und nennt sich nur anders - k.a.; es geht jedenfalls)

grüße
derRaphael

[haichen]

Ich hab hier noch ein Gif von meiner Testversion für meine LanguageHelper Funktionen auf unicode.