vb@rchiv
VB Classic
VB.NET
ADO.NET
VBA
C#
NEU! sevCoolbar 3.0 - Professionelle Toolbars im modernen Design!  
 vb@rchiv Quick-Search: Suche startenErweiterte Suche starten   Impressum  | Datenschutz  | vb@rchiv CD Vol.6  | Shop Copyright ©2000-2024
 
zurück

 Sie sind aktuell nicht angemeldet.Funktionen: Einloggen  |  Neu registrieren  |  Suchen

Fortgeschrittene Programmierung
StrConv auf einem DBCS-System (z.B. China-Taiwan) 
Autor: Woellmi
Datum: 05.02.18 17:55

Hallo zusammen,

damit meine VB6 Anwendung auch auf einem echten chinesischen Rechner funktioniert,
muss ich einige meiner Funktionen umschreiben, damit diese mit UNICode zurechtkommen.
Dabei komme eigentlich ganz gut voran.

Aktuell verzweifle ich an einem scheinbar einfachen Problem.

Nur so zur Info:
Ich erstelle direkt aus VB6 heraus eigene PDF-Reports und verwende dazu
die Klasse "clsPDF" Quelle: vb-tec.de.

Um eine Grafik z.B. Kopfzeilenbild in der PDF-Datei abzulegen, wird in einem Byte-Array (RLE)
der Code einer Grafik abgelegt. Um diese dann in den PDF-Stream einzubinden wird das Array in
einen unicode-String gewandelt. Auf meinen PC mit deutschen OS (also SBCS) erfolgt dies aktuell so:

sString = StrConv(RLE, vbUnicode)
.. und funktioniert seit Jahren prima. Aber eben auf ANSI PC's.

Aus dem Array "RLE" mit (0..95262) Byte resultiert ein String mit LenB(sString) = 190526;
dies ist soweit OK und funktioniert prima.

Auf dem chinesischen PC führt der identische Befehl aber zu folgendem Ergebnis:
Aus dem Array RLE mit (0..95262) Byte resultiert ein String mit LenB(sString) = 113796;

.. was definitiv zu kurz ist.

Und bei der Rücktransformation:
abArray = StrConv(sString, vbFromUnicode)
resultiert ein ByteArray mit (0..85028) Byte und dies entspricht definitiv nicht dem Original.
Auf meinem Original ANSI System funktioniert es in beide Richtungen.

Um die ganze Sache zu testen habe ich mir eine VM aufgesetzt und ein deutsches XP
mit installierter VB6 Entwicklungsumgebung in eine UNIcode Maschine mit Chinesisch(Taiwan)
Ländereinstellung umgewandelt. Nur so konnte ich überhaut etwas testen.

Irgendwie benötige ich wohl einen kleinen Schupps in die richtige Richtung.
Kann mir bitte jemand auf die Sprünge helfen?

Vielen Dank schon jetzt.

Tschaui
Woellmi

Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: StrConv auf einem DBCS-System (z.B. China-Taiwan) 
Autor: Blackbox
Datum: 05.02.18 20:17

Hallo Woellmi,
StrConv hat Konstante für verschiedene asiatische Dialekte.
vbFromUnicode ist für alle Unicode-Variante. Das bedeutet aber,
dass Vb intern Unicode in einen BSTR (CCOMBSTR) umsetzt und diese
dann als String verwendet. VB verwendet nur diesen BSTR.

Zur Erinnerung ein BSTR ist Speicher, der mit der Anzahl der Zeichen in dem
String und dann die eigentlichen Buchstaben in Unicode sind. Somit:

"10 H e l l o" .... Würde VB als String für "Hello" umgesetzt aussehen, obwohl
Hello, da sind wir uns einig, nur 5 Buchstaben enthält.

Da ich Dein Problem nicht direkt nachvollziehen kann ein Vorschlag:
nehme anstatt der Konstante

vbUnicode
vbFromUnicode

diese Konstante:
vbWide

ich habe diese Konstante für mich noch nie gebraucht.

Beitrag wurde zuletzt am 05.02.18 um 20:32:59 editiert.
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: StrConv auf einem DBCS-System (z.B. China-Taiwan) 
Autor: Woellmi
Datum: 06.02.18 08:37

Hallo Blackbox,

danke für Deine Info.

Dies hatte ich auch gedacht. Es sieht ja in der Doku so aus, als ob "vbWide" und "vbNarrow"
extra für den asiatischen Bereich als Entsprechungen zu "vbUniCode" und "vbFromUniCode"
gedacht sind, doch leider bringt dies nichts.

Ich habe es mal anders probiert, und so wenigstens eine 1:1 Hin- und Rückwandlung geschafft.
Folgender Code bringt tatsächlich auf deutschen, wie auf chinesischen Rechnern das identische Ergebnis.
Ich weise dem Befehl zu, dass er nicht mit der System LOCID, sondern immer mit der deutschen LOCID
arbeiten soll.
Dim abtA1() As Byte
Dim abtA2() As Byte
Dim sT1 As String
 
Redim abtA1(3)
abtA1(0) = 46
abtA1(1) = 47
abtA1(2) = 48
abtA1(3) = 49
 
'//1. ANSI Byte-Array in String wandeln
sT1 = StrCov(abtA1, vbUnicode, 7&)
'//Test:  LenB(sT1) => 8 => OK
 
'//2. Test Rücktransformation: String in ANSI Byte-Array
abtA2 = StrConv(sT1, vbFromUnicode, 7&)
'//Kontrolle: abtA1 == abtA2   => OK, klappt also
Nun kommt die nächste Hürde. Die Umwandlung hat scheinbar geklappt, nun muss der
neue String in den Stream eingepflanzt werden.
D.h. ein vorhandener String wird um die Länge des Neuen "sT1" erweitert,
also in diesem Fall "8 Spaces" und dann wird per "MID$" der neue String eingepflanzt.
Auch hier klappt etwas im Unicode System noch nicht.
Mal sehen, wie man dies hier ändern muss.

Also vielen Dank "Blackbox".

Es ist schon seltsam, an was man alles denken muss, um auf einem Unicode System
funktionsfähig zu bleiben. Und dabei geht es noch nicht einmal um die Darstellung von
chinesischen Schriftzeichen.

Tschaui
Woellmi

Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: StrConv auf einem DBCS-System (z.B. China-Taiwan) 
Autor: Blackbox
Datum: 06.02.18 09:21

Hallo Woelmi,

*lange_Antwort_on*
denke daran, dass VB Funktionen extra für UniCode hat. Diese Funktionen enden mit einem W.
ChrW ... usw und auch MIDB(). Mit dem Object Browser kannst du diese spezielle Funktionen sehen. Und wenn gar nichts will, so tun eigene Typen Wunder. Es ist schier unglaublich, wie schräg VB UDT's intern umsetzt.
Am Anfang eines Projekts sollte man sich in VB entscheiden, ob die Anwendung vollen Unicode Support bietet oder nicht. Diese erweiterten Funktionen sollte man also, wenn man sich für Unicode entschieden hat, immer verwendet werden und nicht nur in ein paar Prozeduren.
*lange_Antwort_off*

Kurze Antwort: Nimm die MIDB()-Funktion ;)

Beitrag wurde zuletzt am 06.02.18 um 09:26:31 editiert.
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: StrConv auf einem DBCS-System (z.B. China-Taiwan) 
Autor: Woellmi
Datum: 06.02.18 17:32

Hallo Blackbox,

danke für die Hinweise.
- mein Projekt sehr alt und sehr groß
- seit "2 Jahrzehnten!" war UNICODE für "dieses Projekt" uninteressant
(wie für alle anderen Projekte auch)
- jetzt plötzlich kommt die Anforderung (toll)
=> Ein schneller Umstieg ist praktisch unmöglich! (z.B. C# o.ä.)
- Ich möchte erreichen/rausbekommen, dass/ob die Anwendung in den wesentlichen
Funktionen brauchbar/änderbar ist.
=> Nun wird der Aufwand gescheckt, mal sehen was geht. [bisher recht viel ]
- Es werden nur 2 Sprachen primär unterstützt ENU+GER (die Controls sind ja in der GUI
auch nicht alle Unicode fähig) (Ich weis, es steht die Frage: Macht dass alles Sinn?)
- Es geht nun schon erstaunlich viel und mir liegen einige Funktionen sehr am Herzen.
Doch gerade hier ist viel Testen erforderlich

Die andere Frage ist, wie schnell komme ich mit z.B. C# zu einem Ergebnis,
was diesem Projekt funktionell nahe kommt. Da in der "normalen" Arbeitszeit
praktisch keine Zeit zum "Lernen" gewährt wird (!), müsste ich "wie damals mit VB2-6"
und aktuell mit C# wieder alles zu hause lernen. Da bin ich ja schon wieder dabei,
aber auch dies dauert. Produktiv sein sieht anders aus.
Nun genug gejammert.

Ich hatte doch geschrieben, dass ich mit:
sT1 = StrConv(abtA1(), vbUnicode, 7&)
.. auf beiden Systemen zum identischen Ergebnis gekommen bin.
Leider gilt dies nur für meine wenigen Testdaten und die resultierende String-Länge (Len + LenB).
Beim Originalbild (10kByte) weichen auf dem Unicode System doch wieder ettliche Zeichen ab,
wieso auch immer.
Also nochmal von vorn. Bzw. Fkt. "Bild in PDF" wird abgeschaltet, der Rest funktioniert.

Jetzt werde ich erstmal weiter im Netz recherchieren. Evtl. finde ich ja doch noch
einen brauchbaren Ansatz.

Vielen Dank für die Antwort und sorry für meine langen Texte

Tschaui
Woellmi

Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Woellmi, du bist ein Globalisierungsopfer  
Autor: Blackbox
Datum: 06.02.18 19:15

es gibt überall welche.
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Sie sind nicht angemeldet!
Um auf diesen Beitrag zu antworten oder neue Beiträge schreiben zu können, müssen Sie sich zunächst anmelden.

Einloggen  |  Neu registrieren

Funktionen:  Zum Thema  |  GesamtübersichtSuchen 

nach obenzurück
 
   

Copyright ©2000-2024 vb@rchiv Dieter Otter
Alle Rechte vorbehalten.
Microsoft, Windows und Visual Basic sind entweder eingetragene Marken oder Marken der Microsoft Corporation in den USA und/oder anderen Ländern. Weitere auf dieser Homepage aufgeführten Produkt- und Firmennamen können geschützte Marken ihrer jeweiligen Inhaber sein.

Diese Seiten wurden optimiert für eine Bildschirmauflösung von mind. 1280x1024 Pixel