Tweet
Hallo liebe Delphianer,<br>
habe in einer AccessXP-Datenbank tschechische Sonderzeichen, also hptsl. Buchstaben mit Hatscheks (dem umgekehrten Zirkumflex v). Wenn ich mit ADO darauf zugreife, werden sie mit dem Befehl<pre>Feldinhalt:=vartostr(adodataset1['Feld']);</pre>(Feldinhalt ist vom Typ String) leider in normale Buchstaben ohne Hatschek umgewandelt.
Erst dachte ich, das liegt an ADO, aber dann änderte ich das in zwei Befehle:<pre>varFeldinhalt:=adodataset1['Feld'];<br>Feldinhalt:=vartostr(VarFeldinhalt);</pre>(varFeldinhalt ist vom Typ Variant)
Jetzt Haltepunkt auf die zweite Zeile setzen und staunen:
Fährt man mit der Maus auf die Variable varFeldinhalt, wird einem im Tooltip deren Wert angezeigt, UND ZWAR VÖLLIG KORREKT!!!<br><br>Es ist die vartostr-Funktion, die erst alles zerstört.<br><br><schimpf>Was nützt einem die vielgepriesene Unicode-Fähigkeit von Delphi 2005, wenn das zwar viele Komponenten können (auch ausm Internet besorgbar), aber elementare Funktionen nich, und einem so die Programmiermöglichkeiten nehmen?</schimpf><br><br>Weitere Operationen, die ich mit dem Feldinhalt durchführen muß, setzen nun mal eine Stringvariable voraus. Gibt es keine Funktion vartounicodestr()?
Ich dachte, ich schreibe mir selbst eine, aber wie komme ich dazu an die Zeichen ran? Ich kann nichtmal die Byte-Werte ermitteln, es gibt immer einen Lfz-Fehler der Art: Variable kann nicht in Integer/Byte/Wasauchimmer umgewandelt werden.
Warum gibts eigentlich keine vartohex, vartobyte, vartoirgendwaswomitmanwasanfangenkann-Funktion?<br><br>Gibt ja auch diese Unicode-Codierung '& #268;'. Die wäre schon hilfreich, denn letztlich soll alles sowieso ins Internet gestellt werden. Hab also einfach mal auf Verdacht folgendes versucht:<pre>varFeldinhalt:=adodataset1['Feld'];<br>if copy(varFeldinhalt,1,1)=' ' then Feldinhalt:='& #268;'+copy(varFeldinhalt,2,length(varFeldinhalt)-1);</pre>(das ist jetzt nur Pseudocode, ich bin komplizierter in einer Schleife alle Zeichen durchgegangen. Programm wird dadurch natürlich irre schnell)
Das klappte sogar, aber ich bekam bei einem ganz normalen 'C' ebenfalls den Unicode-Ersatzstring. Wieso um Himmels Willen denn das jetzt wieder???
Außerdem konnte kleines h nicht von großem H unterschieden werden... kurz: unbrauchbar.<br><br>Also:
Was hat der Debugger-Tooltip, was ich nicht hab? Geht das nachzubauen?
Hat jemand ne Lösung oder´n anderen Workaround?
Kann einfach nicht glauben, daß Borland so schlampig arbeitet... (provozier)<br><br>Alex
habe in einer AccessXP-Datenbank tschechische Sonderzeichen, also hptsl. Buchstaben mit Hatscheks (dem umgekehrten Zirkumflex v). Wenn ich mit ADO darauf zugreife, werden sie mit dem Befehl<pre>Feldinhalt:=vartostr(adodataset1['Feld']);</pre>(Feldinhalt ist vom Typ String) leider in normale Buchstaben ohne Hatschek umgewandelt.
Erst dachte ich, das liegt an ADO, aber dann änderte ich das in zwei Befehle:<pre>varFeldinhalt:=adodataset1['Feld'];<br>Feldinhalt:=vartostr(VarFeldinhalt);</pre>(varFeldinhalt ist vom Typ Variant)
Jetzt Haltepunkt auf die zweite Zeile setzen und staunen:
Fährt man mit der Maus auf die Variable varFeldinhalt, wird einem im Tooltip deren Wert angezeigt, UND ZWAR VÖLLIG KORREKT!!!<br><br>Es ist die vartostr-Funktion, die erst alles zerstört.<br><br><schimpf>Was nützt einem die vielgepriesene Unicode-Fähigkeit von Delphi 2005, wenn das zwar viele Komponenten können (auch ausm Internet besorgbar), aber elementare Funktionen nich, und einem so die Programmiermöglichkeiten nehmen?</schimpf><br><br>Weitere Operationen, die ich mit dem Feldinhalt durchführen muß, setzen nun mal eine Stringvariable voraus. Gibt es keine Funktion vartounicodestr()?
Ich dachte, ich schreibe mir selbst eine, aber wie komme ich dazu an die Zeichen ran? Ich kann nichtmal die Byte-Werte ermitteln, es gibt immer einen Lfz-Fehler der Art: Variable kann nicht in Integer/Byte/Wasauchimmer umgewandelt werden.
Warum gibts eigentlich keine vartohex, vartobyte, vartoirgendwaswomitmanwasanfangenkann-Funktion?<br><br>Gibt ja auch diese Unicode-Codierung '& #268;'. Die wäre schon hilfreich, denn letztlich soll alles sowieso ins Internet gestellt werden. Hab also einfach mal auf Verdacht folgendes versucht:<pre>varFeldinhalt:=adodataset1['Feld'];<br>if copy(varFeldinhalt,1,1)=' ' then Feldinhalt:='& #268;'+copy(varFeldinhalt,2,length(varFeldinhalt)-1);</pre>(das ist jetzt nur Pseudocode, ich bin komplizierter in einer Schleife alle Zeichen durchgegangen. Programm wird dadurch natürlich irre schnell)
Das klappte sogar, aber ich bekam bei einem ganz normalen 'C' ebenfalls den Unicode-Ersatzstring. Wieso um Himmels Willen denn das jetzt wieder???
Außerdem konnte kleines h nicht von großem H unterschieden werden... kurz: unbrauchbar.<br><br>Also:
Was hat der Debugger-Tooltip, was ich nicht hab? Geht das nachzubauen?
Hat jemand ne Lösung oder´n anderen Workaround?
Kann einfach nicht glauben, daß Borland so schlampig arbeitet... (provozier)<br><br>Alex
Comment