Ich möchte gerne einen Boolean in Stringform anzeigen. Dazu wollte ich BoolVar.ToString nutzen. Leider btingt mir das immer den Zahlenwert, also 0 oder -1. Die Boolean.ToString Helperfunktionen scheinen nicht zu funktionieren. Da läuft irgendwas mit den Default Parametern der Helperklasse und ser Sysutils.BooToStr Funktion ziemlich falsch.

zusammenfalten · markieren

Delphi-Quellcode:

var
  b: Boolean;
  s: String;
begin
  b := True;
  s := b.ToString; // liefert '-1'
  s := b.ToString(True); // Liefert '-1', müsste aber 'True' liefern

  b := False;
  s := b.ToString; // liefert '0'
  s := b.ToString(True); // Liefert '-1' ?! Der True Parameter müsste steuern, ob die BooleStr verwendet werden sollen (UseBooleStrs)!

Ich nehme immer meinBoolean.ToInteger().ToString() , damit bekommst du 0 für False und 1 für True ��

Hi,

habe das gerade ausprobiert und das gleiche Verhalten wie Rolf. Irgendwie kommt der Compiler mit der überladenen Funktion vom Helper durcheinander. Wenn man der .ToString-Methode True übergibt (ruft BoolToStr auf), interpretiert das die aufgerufene BoolToStr-Methode komischerweise als False. Es funktioniert nur, wenn den gewünschten Parameter TUseBoolStrs.True benutzt wird, obwohl TUseBoolStrs ja auf True oder False verweist, was irgendwie komisch ist.

markieren

Delphi-Quellcode:

  var
    b: Boolean;
    s: string;
  begin
    b := True;
    s := b.ToString; //-1, richtig
    s := b.ToString(True); //-1, obwohl 'True' erwartet, siehe Rolfs Kommentar
    s := b.ToString(TUseBoolStrs.True); //'True', richtig
    s := BoolToStr(b, True); //'True', richtig
  end;

Die Rückgabe von 0 und -1 ist richtig, siehe Doku:
https://docwiki.embarcadero.com/Libr...tils.BoolToStr

Als Alternative kannst du einfach s := BoolToStr(b, True); benutzen.

Was funktioniert ist:
 s := b.ToString(TUseBoolStrs.True); hier wird im class helper nicht richtige Funktion verwendet. (zumindest in meinen Beispiel)
True <> TUseBoolStrs.True

Ja das mit dem TUseBoolStrs.True habe ich unterdessen auch rausgefunden. Bool.ToString(TUseBoolStrs.True) liefert "True", Bool.ToString(True) liefert "-1".

Hat da wer eine plausible Erklärung für dieses Verhalten und wieso man da unbedingt TUseBoolStrs.True nutzen muss?

Das siehst du doch eigentlich direkt auf den ersten Blick:

entfernt - habe mich geirrt

Zitat von Rolf Frei:

Hat da wer eine plausible Erklärung für dieses Verhalten und wieso man da unbedingt TUseBoolStrs.True nutzen muss?

Na ja, in einem Fall wird halt die class function aufgerufen, deren erster Parameter der umzuwandelnde Boolean ist. Der optionale zweite Parameter gibt dann die Darstellung an.

Bei der regulären function gibt es nur den optionalen Parameter für die Darstellung.

Problematisch ist hier die Kombination von Overloads und optionalen Parametern gepaart mit der Kollision des zu bearbeitenden Typs (Boolean) und dem erwarteten Parameter für die Darstellung (ebenfalls Boolean). Diese Kollision wurde mit dem neuen Typ TUseBoolStrs umgangen. Leider passt das nicht mehr zur Erwartungshaltung des Entwicklers.

Es gibt aber auch Meinungen, dass ein Aufruf einer class function nur über die Angabe des Typs und nicht einer Variablen des Typs gehen dürfte. Ich fürchte nur, dass eine solche Einschränkungen eine Menge Code nicht mehr compilieren ließe.

Ok danke für die Erläuterung. Wenn ich da als Anwender den Defaultwert False in der Parmaterliste sehe, komme ich nicht dirket auf die Idee, da TUseBoolStrs.True zu verwenden. Wäre dort der Defaultwert mit TUseBoolStrs.False angezeigt worden, wäre es wohl deutlich klarer gewesen.

Zitat von Rolf Frei:

Wäre dort der Defaultwert mit TUseBoolStrs.False angezeigt worden, wäre es wohl deutlich klarer gewesen.

Das stimmt allerdings.

Hätten wir einen funktionierenden Bugtracker oder Feedback-System bei Embarcadero, könnte man das sogar dort einreichen.