Selsames verhalten bei True abfrage

[EWeiss]

Habe ein problem bei mit einer simplen abfrage

Delphi-Quellcode:

if AppOwnHdcW2 = True then
begin

Delphi-Quellcode:

if (AppOwnHdcW2 = True) then
begin

alle diese abfragen liefern ein False zurück obwohl die eigenschaft AppOwnHdcW2 True ist!

Nur das funktioniert

Delphi-Quellcode:

if AppOwnHdcW2 then
begin

Wo ist das problem ?

gruss Emil

[SirThornberry]

Das ist kein Problem von Delphi sondern ein Problem welches sich der Programmierer selbst einproggt. Wahr ist alles ungleich 0. False ist also 0. True ist in Delphi 1. Aber Wahr ist eben nicht nur 1 sondern alles ungleich 0.
Deswegen sollte man auch nie einen Boolean mit True vergleichen außer man will wirklich wissen ob der Boolean den Wert 1 hat.
Zudem hat die cpu mehr zu tun wenn du auf True vergleichst anstelle nur den Boolean als Bedingung zu nehmen (weil ja sonst erst geprüft werden muss ob 2 Variablen identich sind und dann ob der vergleich wahr ist)

Wenn du also AppOwnHdcW2 mal zu Byte oder Integer castest wirst du sehen das es eine Zahl ungleich 1 ist.

[3_of_8]

Ich vermute, dass AppOwnHdcW2 -1 ist. Bei LongBool ist True nämlich IIRC -1, bei Boolean 1.

[Matze]

Siehe dir hierzu auch mal das hier an: Über den Umgang mit Boolean.

[EWeiss]

Zitat:

Zitat von Matze

Siehe dir hierzu auch mal das hier an: Über den Umgang mit Boolean.

Das muss ich mir nicht antun
Wie der wert Boolean interpretiert wird ist mir wohl klar.

Ich denke das ist ein bug in Delphi.
Wenn ich einen Wert strikt als boolean definiere erwarte ich auch das nur auf true
oder false geprüft wird und nicht auf integer oder byte werte.

Dann kann ich ihn direkt als integer oder longbool deklarieren.

Ja bool ist in diesen Fall -1 da aus einer VB Anwendung übergeben.
Aber auch das muss eine interpreter sprache erkennen von wo der Wert übergeben wird.

In VB gibt es kein 0=False 1=True da ist -1=False und 0=True.

Auch wenn ich die DLL in Delphi geschriebe habe kann ich aus VB nicht einfach mal 0 oder 1 übergeben.

gruss Emil

[mkinzler]

Nein, es ist kein Delphi-Fehler. Man vergleicht halt grundsätzlich nicht auf True oder False!

[EWeiss]

Zitat:

Zitat von mkinzler

Nein, es ist kein Delphi-Fehler. Man vergleicht halt grundsätzlich nicht auf True oder False!

Beispiel:

Delphi-Quellcode:

            VisChan = BASS_WINAMPVIS_ExecuteVis(PluginDir & "\" & _
                      lstPlugins.List(IndexNum), _
                      VisModules.ListIndex, _
                      True, _
                      ckOwnDcW2.value)

Funktioniert!

Delphi-Quellcode:

            VisChan = BASS_WINAMPVIS_ExecuteVis(PluginDir & "\" & _
                      lstPlugins.List(IndexNum), _
                      VisModules.ListIndex, _
                      True, _
                      True)

Funktioniert nicht!

Beides das selbe nur das beim obigen die Value des Controls übergeben wird.
Selbst wenn jetzt der Wert von ckOwnDcW2.value(control) als -1 und 0 übergeben wird kommt es immer
noch nicht mit der aussage überein 0 und 1 in Delphi da nie ein wert von 1 übergeben wird.

Na es geht ja !
Ansonsten würden sich die Plugins nicht in mein GenFenster setzen.
Aber seltsam ist das schon.

gruss Emil

[Christian Seehase]

Moin Emil,

dann liegt der Fehler wohl nicht bei Delphi, sondern in der Funktion, die Du aufrufst.
Dort wird dann offensichtlich auf = true geprüft, wobei dort true als -1 angesehen wird.

Zitat:

Zitat von EWeiss

Selbst wenn jetzt der Wert von ckOwnDcW2.value(control) als -1 und 0 übergeben wird kommt es immer
noch nicht mit der aussage überein 0 und 1 in Delphi da nie ein wert von 1 übergeben wird.

Den Satz habe ich nicht ganz verstanden.
Was meinst Du damit?

[EWeiss]

Zitat:

Zitat von Christian Seehase

Moin Emil,

Zitat:

Zitat von EWeiss

Selbst wenn jetzt der Wert von ckOwnDcW2.value(control) als -1 und 0 übergeben wird kommt es immer
noch nicht mit der aussage überein 0 und 1 in Delphi da nie ein wert von 1 übergeben wird.

Den Satz habe ich nicht ganz verstanden.
Was meinst Du damit?

damit meinte ich diese aussage

Zitat:

Wahr ist alles ungleich 0. False ist also 0. True ist in Delphi 1. Aber Wahr ist eben nicht nur 1 sondern alles ungleich 0.

Wenn ich aus VB '-1 oder 0' für boolean sende kann in Delphi niemals der wert '1 = true' eintreten
da der höchste wert = 0 ist.

gruss Emil

[Christian Seehase]

Moin Emil,

Zitat:

Zitat von EWeiss

Wenn ich aus VB '-1 oder 0' für boolean sende kann in Delphi niemals der wert '1 = true' eintreten

und deshalb prüft man nie auf = true ;-)

Um Boolsche-Variablen sprechend initialisieren zu können muss man sich für einen Wert entscheiden, der für true steht, in Delphi ist das dann halt 1, in VB -1.

[EWeiss]

Zitat:

Zitat von Christian Seehase

Moin Emil,

Zitat:

Zitat von EWeiss

Wenn ich aus VB '-1 oder 0' für boolean sende kann in Delphi niemals der wert '1 = true' eintreten

und deshalb prüft man nie auf = true ;-)

Um Boolsche-Variablen sprechend initialisieren zu können muss man sich für einen Wert entscheiden, der für true steht, in Delphi ist das dann halt 1, in VB -1.

Ja danke.. ;)
habs jetzt so geändert das es Sprachunabhängig ist..

gruss Emil

[Amateurprofi]

Zitat:

Zitat von SirThornberry

Zudem hat die cpu mehr zu tun wenn du auf True vergleichst anstelle nur den Boolean als Bedingung zu nehmen (weil ja sonst erst geprüft werden muss ob 2 Variablen identich sind und dann ob der vergleich wahr ist)

@SirThornberry

Das ist so nicht ganz richtig.

ein "if a=true then " wird umgesetzt in

Delphi-Quellcode:

cmp a,1
jnz xxxx  // wenn a nicht true ist

ein "if a then" wird umgesetzt in

Delphi-Quellcode:

cmp a,0
jz xxx  // wenn a = 0 also false ist

ob die CPU gegen 0 oder 1 prüft macht (vom Aufwand her) keinen Unterschied.

Ansonsten hast Du natürlich Recht mit der Aussage "nie mit True vergleichen.."

[himitsu]

Auf True sollte man halt nie prüfen, es sei denn man will/muß ganz genau wissen, ob es wirklich mit True identisch ist.

also im Normalfall immer nur:
B
not B

oder maximal noch,
B <> False
da False immer nur 0 ist.
(wobei es eigentlich besser wäre gleich auf alle "=/<> true/false" zu verzichten)


Und nochmals: nein, kein Bug ... schließlich will man manchmal auch genau dieses Verhalten (B = True, also True <> True) haben.

[Muehle]

Zu

AppOwnHdcW2 = True (*)


Also mal grundsätzlich falls AppOwnHdcW2 boolean ist, dann
dürfte es eigentlich kein Problem geben !!!

Ist jedoch AppOwnHdcW2 ein Handle, so wie es aussieht,
so hat sich eingebürgert :

if AppOwnHdcW2 then

Grund :

Handle = nil -> Bedingung wird als false interpretiert,
ansonsten true.

Es gilt also folgende Regel :

Vergl. mit true/false nur bei boolean

ansonsten je nach Programmiersprache erstmal schauen,
wie:

if wert then

interpretiert wird.

[mkinzler]

Zitat:

Vergl. mit true/false nur bei boolean

Nein bei Boolean entfällt der Vergleich:

Delphi-Quellcode:

if b

oder

Delphi-Quellcode:

if not b

und auf nicht if b = true

[Muetze1]

Zitat:

Zitat von Muehle

Ist jedoch AppOwnHdcW2 ein Handle, so wie es aussieht, so hat sich eingebürgert :

Code:

if AppOwnHdcW2 then

Grund :

Handle = nil -> Bedingung wird als false interpretiert,
ansonsten true.

Nein! Wenn du selber sagst, dass es ein Handle ist, dann ist es kein boolscher Ausdruck und das wird dir der Compiler um die Ohren hauen. Das hat sich vielleicht bei C/C++ eingebürgert, aber nicht bei Delphi, da Delphi nicht standardmässig Ordinaltypen (ausser Boolean) auf Ungleichheit mit 0 prüft!

Bei Boolean gilt auch grundsätzlich der Hinweis von mkinzler...

[Muehle]

zu mkinzler :

natürlich hast du da recht, da kürzer.

jedoch ist if (a=false) zumindest nicht falsch, falls a boolean ist.

Gruß G.M.

[himitsu]

hab's dochauch schon gesagt ... mit/auf FALSE könnte man prüfen, aber da es mit TRUE nicht geht, ist es besser dieses gleich ganz sein zu lassen.

Viele machen ja schließlich nur das nach, was sie irgendwo sehn und denken sich womöglich mit FALSE arbeiten ja viele, warum soll ich's dann nicht auch mit TRUE versuchen ... und irgendwann landen die dann wieder hier und wundern sich weil irgendwas nicht geht.

[jbg]

Zitat:

Zitat von EWeiss

Ich denke das ist ein bug in Delphi.
Wenn ich einen Wert strikt als boolean definiere erwarte ich auch das nur auf true
oder false geprüft wird und nicht auf integer oder byte werte.

Nein es ist ein Bug in deiner Deklaration. Wenn du von VB eine Boolschen Wert bekommen willst oder reinreichst, musst du den Datentyp LongBool/WordBool/ByteBool statt Boolean verwenden. Delphi macht dann ganz automatisch die Übersetzung von -1 nach 1 bzw. andersherum.

Delphi-Quellcode:

var
  lb: LongBool;
  b: Boolean;
begin
  lb := True;
{ 83C8FF           or eax,-$01  }
  b := lb;
{ 83F801           cmp eax,$01
  1BC0             sbb eax,eax
  40               inc eax      }
  if b = True then
{ 3C01             cmp al,$01
  7505             jnz +$05     }
    ShowMessage('Ist True');
end;