Problem mit #0 im String

[alzaimar]

Das ist mal wieder ein typischer Anwendungsfall von 'Trenne Funktion und Darstellung'.

Die Funktion (hier: HEX->binär) funktioniert, mur für die Darstellung muss man eine andere Form wählen (z.B. wie Satty67 es vorgeschlagen hat).

Falsch im Sinne des o.g. Paradigmas ist es, ein Darstellungselement (Edit2) als Funktionselement zu verwenden (Zwischenspeicher).

[R2009]

Hi alzaimar,

Zitat:

Falsch im Sinne des o.g. Paradigmas ist es, ein Darstellungselement (Edit2) als Funktionselement zu verwenden (Zwischenspeicher).

Im Prinzip stimme ich dir zu!
Ich finde es halt schade, dass an dieser Stelle plötzlich die Philosophie (interne Darstellung von Variablen) einfach gewechselt wird.
Ich bin davon ausgegangen, dass in Object pascal, alle Strings auch als "Delphi Strings" behandelt werden.
Wer kommt denn auf die Idee, dass da plötzlich mit "0" terminierten Strings operiert wird.
Das hat nichts mit Darstellungs oder Funktionselementen zu tun sondern mit der Konsequenz mit der eine Programmiersprache
realisiert wird.

Viele Grüsse

[Bernhard Geyer]

Zitat:

Zitat von R2009

Ich finde es halt schade, dass an dieser Stelle plötzlich die Philosophie (interne Darstellung von Variablen) einfach gewechselt wird.
Ich bin davon ausgegangen, dass in Object pascal, alle Strings auch als "Delphi Strings" behandelt werden.
Wer kommt denn auf die Idee, dass da plötzlich mit "0" terminierten Strings operiert wird.

Delphi hat bei Strings schon eine durchgehende Philosophie. Da jedoch alle Controls (TEdit, ...) nur Wrapper um die entsprechenden Win32-API-Controls sind wird auf dieser Ebene zwangsweise #0 als Trenner angesehen da die Win32-API eine C-Kompatible schnittstelle darstellt. Und dort heißt nunmal #0 = String-Ende

[Satty67]

Zitat:

Zitat von R2009

Wer kommt denn auf die Idee, dass da plötzlich mit "0" terminierten Strings operiert wird.

Das ist die Forderung des ComControl von Windows, da kann Delphi nichts dafür. Windows arbeitet schon immer mit NUL-terminierten Strings, ich glaube nicht, dass das irgendwann einmal unter Windows ging. :gruebel:

Delphi übergibt an das Windows-Element evtl. sogar ein '1234'#0'6789'#0#0. Nur schneiden Windows Funktion den String vor seiner Sichtbarkeit ab. Ich bin sogar relativ sicher, dass Du in keiner Programmiersprache ein #0 in einem Windows-Edit sichtbar machen kannst.

[R2009]

Hi,

Bernhard Geyer schrieb:

Zitat:

nur Wrapper um die entsprechenden Win32-API-Controls

OK, das muss man wissen.
Was mich stört ist weniger, dass man die "0" nicht sieht, (damit hab ich gerechnet)
Mich stört, dass wenn ich edit1.text einen String zuweise der eine "0" enthält entweder die Setter Methode oder die Getter Methode den Rest abschneidet.
Täusch ich mich oder ist das Object Pascal?
Oder existiert edit1.text als String überhaupt nicht?
Das heisst wird das direkt dem Windows Steuerelement zugewiesen und von da auch wieder geholt?

Naja eine einfache Lösung hab ich jetzt ich stelle die Dinge halt in Hex dar.

Vielen Dank!

[mkinzler]

Ist aus der Vererbungshierarchie ersichtlich -> TWinControl

[Bernhard Geyer]

Zitat:

Zitat von R2009

Bernhard Geyer schrieb:

Zitat:

nur Wrapper um die entsprechenden Win32-API-Controls

OK, das muss man wissen.

Das war ja die Absicht der VCL. Die Kapslung der Win32 möglichst gut durch zuführen.
Aber auch wenn es ein Wrapper um KDE oder MacOS-Controls wäre, würde zu 99,9% das gleiche passieren.

[generic]

Eigentlich ist das Thema hier, die aus C bekannten Null terminierten Strings.
Das #0 Zeichen gibt das Ende des Strings an.
Bei Pascalstrings steht die Länge des Strings vor dem ersten Zeichen im Speicher.
Da Windows in C geschrieben ist, kommt das #0 zum Tragen bei der Anzeige.

Delphi hat C kompatible Strings. Diese haben wie Pascal die Länge vor dem ersten Zeichen gespeichert und Terminieren noch zusätzlich den String mit #0.
Daher kann die Windows API so Klasse angesprochen werden.

[QuickAndDirty]

Gibt es eine fertige C-Escape Funktion? Also eine Funktion die automatisch alles was in C-Escaped werden muss in einem PChar mit vernünftigen Escape Zeichen umwandelt?

'c:\dummesBeispiel\' -> 'c:\\dummesBeispiel\\'
'Meintext'#9'deintext' -> 'Meintext\tdeintext'
#0 -> '\0'
&c.

[thkerkmann]

Das würde dir auch nicht helfen, da das nur die Darstellung für den Compiler ist, und nicht die interne binäre Speicherung.