Autoit if Fehler

manuel6000

Bei mir wird bei Autoit trotz einer if Abfrage alles ausgeführt wenn die Variable den Wert 0 hat?

[autoit]

$a = 0
If $a = "ajugdaid" Then MsgBox(0,"","")

[/autoit]

**minx**

0 ist falsch
"ajugdaid" ist ebenfalls falsch

ALLES was ncith True ist (oder 1) ist nicht wahr

//GELÖST. Verwende "=="

$var

Zitat von minx

0 ist falsch
"ajugdaid" ist ebenfalls falsch

ALLES was ncith True ist (oder 1) ist nicht wahr

Sollte ein Vergleich mit False dann nicht ebenfalls True sein?

[autoit]

MsgBox(0, '', 0 = 'ajugdaid') ; True
MsgBox(0, '', False = 'ajugdaid') ; False

[/autoit]

Ist er irgendwie nicht...

**minx**

Nein.
$a ist falsch, weil es 0 ist.
Da 'ajugdaid' nicht True ist, ist es eine hinreichende Bedingung, damit bei der logischen Operation "=", die Werte einander entsprechen.
Mit "==" lässt sich auch der Inhalt vergleichen

[autoit]

If Not "lol" Then ConsoleWrite("'lol' ist nicht eindeutig Wahr"&@crlf)

[/autoit][autoit][/autoit][autoit]

If "lol" Then ConsoleWrite("'lol' ist hinreichend Wahr"&@crlf)

If "lol" = 0 Then ConsoleWrite("'lol' entspricht hinreichend 0"&@crlf)

If Not "lol" == 0 Then ConsoleWrite("'lol' entspricht eindeutig nicht 0"&@crlf)

If "lol" = False Then ConsoleWrite("'lol' ist eindeutig Falsch"&@crlf)

If "lol" == True Then ConsoleWrite("'lol' ist eindeutig Wahr"&@crlf)

[/autoit]

$var

Das hast du jetzt aber schnell wegeditiert...

Zitat von minx

Da 'ajugdaid' nicht True ist

Ist es doch.

[autoit]

MsgBox(0, '', True = 'string') ; True

[/autoit]

Allgemein verstehe ich es zwar (glaube ich), aber in diesem Fall ergibt es gar keinen Sinn:

[autoit]

MsgBox(0, '', 0 = False) ; True

[/autoit][autoit][/autoit][autoit]

MsgBox(0, '', 0 = 'string') ; True
MsgBox(0, '', False = 'string') ; False

[/autoit]

Im Endeffekt hat man dann ein (un)logisches True = False.

**minx**

Ein String mit "=" verglichen entspricht hinreichend "0". Irgendwie verwirrend.

[autoit]

MsgBox(0, "", BitAND(("lol"=0),("lol"<>0)))

[/autoit]

"lol" ist also immer 0.

"lol" = 0 ist wahr, und "lol"<>0 ist falsch. Ein String ist also immer 0. :wacko:

**minx**

[autoit]

MsgBox(0, "", ("lol"=True))
MsgBox(0,"",("lol"=True And "lol"=0))
MsgBox(0, "", 0=True)

[/autoit]

Die Fakten:

"lol" entspricht 0
"lol" entspricht True

ABER True <> 0

$var

Vergleiche mit "==" stimmen soweit. Aber darum geht es nicht.

Wenn ein String hinreichend 0 entspricht und 0=False ist, dann müsste der Vergleich eines Strings mit False True ergeben.
Ein String ist also gleichzeitig True und 0. Aber True <> 0...

Die Logik verstehe ich nicht.

Ich will jetzt wirklich keinem auf die Nerven gehen - finde es nur interessant.

**minx**

Ich kapiere es auch nicht, siehe Post über dir

$var

Ja, jetzt schreiben wir hier genau dasselbe.

Vielleicht meldet sich hier ja noch jemand, der mehr dazu sagen kann. Bis dahin sehe ich es als Fehler an.

manuel6000

dann setze ich das mal wieder auf ungelöst wenn ich euch nicht sicher seit

Data

Das ist halt der Nachteil an dynamisch typisierten Programmiersprachen. Auf Wikipedia steht:

Zitat

Eine Typisierung dient in der Informatik dazu, dass die Objekte (hier Objekte im mathematisch-abstrakten Sinne verstanden) der Programmiersprachen, wie z. B. Variablen, Funktionen oder Objekte (im Sinne der objektorientierten Programmierung) korrekt verwendet werden. Ein Ziel der Typisierung ist die Vermeidung von Laufzeitfehlern.

Zitat

Dies wird durch Typsysteme erreicht, die eine Idee aus der Mathematik, speziell der Typentheorie aufgreifen, die durch die Entdeckung von Widersprüchen in der Mengenlehre in eine Grundlagenkrise geraten war, bis man sich darauf besann, genauer darauf zu achten, welche Objekte wie benutzt werden.

Deshalb haben die großen Programmiersprachen wie z. B. Objective-C oder Java alle statische Typisierung.
Nichts gegen AutoIt natürlich... das ist ja eins der Hauptprobleme an den großen Programmiersprachen, das selbst einfache Aufgaben einen gewissen Grundaufwand benötigen. Deshalb habe ich das Programmieren ja auch (autodidaktisch und mit Forenhilfe) mit AutoIt angefangen zu lernen.
Aber u. A. genau auf Grund dieser Logikfehler (denn es ist ein Fehler, dieser einzelne ließe sich zwar durch Arbeiten am Compiler/Interpreter ausmerzen; aber man würde immer neue finden) wurde die statische Typisierung entwickelt. Denn erst einmal ist sie natürlich aufwändiger.

**BugFix**

Die Ursache liegt u.A. in der Verwendung des Datentyps Variant. So praktisch das i.A. ist -- hier tritt es uns in den Hintern.
Folgende Probleme fallen hier zusammen:
- AutoIt hat nicht einen Wert wie z.B. 'nil' in LUA, also das definierte 'Nichts'
- eine frisch deklarierte Variable ohne Wertzuweisung hat nur ein "unklares Nichts" als Wert, sowohl 0 als auch Leerstring sind somit ein "unklares Nichts"

Bei Vergleichen ist es somit zwingend erforderlich nicht Äpfel mit Birnen, sondern Datentypgleich zu vergleichen:

[autoit]

; FALSCH:
$a = 0
If $a = 'abc' Then

[/autoit][autoit][/autoit][autoit]

; RICHTIG:
If $a = 1234

[/autoit][autoit][/autoit][autoit]

; oder RICHTIG
$a = '0'
If $a = 'abc' Then

[/autoit]

Damit ist garantiert, dass der Vergleich auch gewünschte Ergebnisse liefert.

Was passiert in den "gemischten" Abfragen?

[autoit]

$a = 0 ; also ein Integerwert
If $a = "abc" ; laut dieser Abfrage soll ein Vergleich von Integerwert $a=0 mit einem anderen Wert stattfinden.

[/autoit]

Da Variant nun versucht die Werte typgleich zu gestalten wird mit Int("abc") verglichen - und das ergibt: 0
Somit ist 0 = 0 und der Vergleich ist WAHR.
w.z.b.w.

**Andy**

Hi,

es hängt an der Zuordnung (bool) dass true=1 und false=0 ist, bzw programmintern genau so abgearbeitet wird, und zwar während der Interpretation/Compilation. Bei AutoIt wird augenscheinlich auf BOOL eher geprüft als auf 0 oder 1.

[autoit]

$a=false ;entspricht FALSE
msgbox(0,"$a="&$a,isbool($a))
if $a="abc" then msgbox(0,"$a="&$a,$a="abc"); if TRUE then

[/autoit][autoit][/autoit][autoit][/autoit][autoit]

$a=0 ;entspricht NUMBER(0), und das ist immer 1 => TRUE
msgbox(0,"$a="&$a,isbool($a))
if $a="abc" then msgbox(0,"$a="&$a,$a="abc"); if TRUE then

[/autoit]

Wenn man also per IF auf TRUE/FALSE (nicht 0 oder 1 !! ) prüft, dann sollte man die passenden Variablen verwenden.

[autoit]

if 0 then msgbox(0,0,0);0 => false s.o
if 1 then msgbox(0,true,1);number(xx) oder string(xx) => true s.o

[/autoit]

Das führt also dazu, dass ein IF (fürs debugging )so eingesetzt werden sollte:

[autoit]

$a=0
$ausdruck = ($a="abc");umwandlung in bool TRUE/FALSE
msgbox(0,"Ausdruck",$ausdruck)
;abfrage
if $ausdruck=TRUE then msgbox(0,"Ausdruck ist",TRUE)

[/autoit]

BugFix

Zitat

- AutoIt hat nicht einen Wert wie z.B. 'nil' in LUA, also das definierte 'Nichts'

NIL könnte man also imho in AutoIt mit FALSE ersetzen.
Kommt darauf an, WIE bzw. durch was externe Compiler/Interpreter dieses NIL intern ersetzen, bzw. wie weit "oben" dieser Ausdruck in der Prioritätenliste ist.
Man müsste mal dll´s verschiedener Programmiersprachen erstellen, welche dieses "NIL" auswerten, und könnte dann in AutoIt eine Zuordnung treffen.

**BugFix**

Zitat von Andy

NIL könnte man also imho in AutoIt mit FALSE ersetzen.

Jein.
So, wie AutoIt damit umgeht, kann 0 und Leerstring als FALSE betrachtet werden. Das beißt sich aber mit Inhalten bzw. Nicht-Inhalten von Variablen. Dadurch haben Variablen, die ohne Wertzuweisung erstellt werden, leider einen Wert, der als 0, Leerstring oder FALSE gelesen wird.
Abhilfe schafft halt der typenkorrekte Vergleich bzw. das Vorbelegen der Variablen mit eineindeutigen Werten.
Je länger ich mit AutoIt arbeite, desto unglücklicher bin ich mit dem Datentyp Variant. Er verleitet zu schnell zu Fehlern. Selbst eine typgenaue Deklaration schützt nicht davor, dass ein String in einer Integeroperation verwendet wird. Variant als Datentyp passt sich einfach an statt einen Fehler zu bringen, somit kann ein Flüchtigkeitsfehler sich gut verstecken. :wacko:

**Andy**

Ja, das ist klar, aber trotzdem MUSS es eine Priorisierung im Fall der Typen geben.
In dieser Kaskade werden demnach Bool (TRUE/FALSE) eindeutig vor anderen Variablentypen behandelt bzw. ausgewertet.
Die AutoIt-interne Typumwandlung bzw. Zuordnung (im C++-Code) erfolgt ja auch durch etliche Abfragen. Und die Reihenfolge dieser Abfragen bestimmt somit das Ergebnis bzw. den Datentyp.

[autoit]

msgbox(0,0,7*True);hier wird True als 1 interpretiert, und nicht als Ergebnis TRUE ausgegeben...

[/autoit]

/Edit/ das ist eher Philosophisch^^
Ist Sieben mal Wahr gleich Sieben oder ist es Wahr??

/EDIT2/

[autoit]

msgbox(0,0,True+true);Fehlermeldung
msgbox(0,0,(True)+(true));hier wird True als 1 interpretiert
msgbox(0,0,(True)&(true));hier wird True als True interpretiert

[/autoit]

**BugFix**

Zitat von Andy

Und die Reihenfolge dieser Abfragen bestimmt somit das Ergebnis bzw. den Datentyp.

Zitat von Andy

das ist eher Philosophisch^^

Sehe ich auch so.
Diese Abfragelogik erlaubt dann auch solche im ersten Moment seltsam erscheinenden Umwandlungsoperationen:

[autoit]

Func __Bool2Num($bool)
Return BitAND($bool, True)
EndFunc ;==>__Bool2Num

[/autoit][autoit][/autoit][autoit]

Func __Num2Bool($num)
Return Not Not $num
EndFunc ;==>__Num2Bool

[/autoit]

**Andy**

Hehe, genau DAS ist ja das schöne daran
So kann man die "automatische" Typumwandlung beeinflussen, in anderen Programmiersprachen mit "festen" Typen geht das natürlich auch.

Schlusswort:
It´s not a bug, it´s a feature...