Stimmt, man kann natürlich auch die Daten direkt bei das Skript beilegen.
Und ja, zum eigenen Text wollte ich eigentlich nochwas schreiben, habs aber total verpeilt. :wacko:
Wird sofort geändert.^^
chess
[Tutorial] Sauber Programmieren
-
@chess
Spoiler anzeigen
[autoit]
[/autoit] [autoit][/autoit] [autoit]
; Example 1; Eigentlich ist es OK, viele andere
[/autoit] [autoit][/autoit] [autoit]
; und auch ich machen es so.
; Doch wird hier impliziert,
; dass auch Example 2 richtig sein könnte
; (habe ich hier schon gesehen).; Also besser gleich Example 3 !
[/autoit] [autoit][/autoit] [autoit]While 1
[/autoit] [autoit][/autoit] [autoit]
$iMsg = GUIGetMsg()
Switch $iMsg
Case $GUI_EVENT_CLOSE
Exit
EndSwitch
WEnd; Example 2
[/autoit] [autoit][/autoit] [autoit]
While 2
$iMsg = GUIGetMsg()
Switch $iMsg
Case $GUI_EVENT_CLOSE
Exit
EndSwitch
WEnd; Example 3
[/autoit]
While True ;<<<--- Korrekt!
$iMsg = GUIGetMsg()
Switch $iMsg
Case $GUI_EVENT_CLOSE
ExitLoop ;<<<--- Korrekt!
EndSwitch
WEnd
; Ende -
Okay, also:
Das While True ist haargenau dasselbe wie While 1.
In einem Text über den C99-Standard steht sogar das hier:Zitat
Im Prinzip gibt es keine booleschen Variablen. Die Zahl 0 wird als 'falsch' (false) definiert, alle anderen Zahlen interpretiert man als 'wahr' (true).
Quelle
Generell gilt aber (So habe ich es zumindest gelernt), dass man für bool'sche Variablen, Vergleiche oder Operationen genau so gut 0 für False und 1 für True verwenden kann.
Daher würde ich als valide Möglichkeiten True & 1 ansehen.Und was ExitLoop angeht... Welche Gründe soll es dafür geben?
Exit beendet die Anwendung zu 100% (Und du kannst sogar noch eine Exit-Message angeben).ExitLoop verlässt den Loop und ruft evtl. noch irgendwelche Codesnippets auf, die hinter der Mainschleife liegen.
Außerdem kannst du nicht - Wie von Windows vorgesehen - einen Exitcode übergeben.
Daher wird das bei mir bei Exit bleiben - Es sei denn, du gibst uns einen triftigen Grund.
Und, was mir noch auffällt (Was aber eigentlich auch hier im Tutorial überall falsch ist)...
[autoit]
Der Rückgabewert von GUIGetMsg() ist ein Handle, daher sollte es wohl so aussehen:
[/autoit]
While True ;<<<--- Korrekt!
$hMsg = GUIGetMsg()
Switch $hMsg
Case $GUI_EVENT_CLOSE
Exit
EndSwitch
WEndOder sind Events kein Handle?
lg chess
-
Der Rückgabewert von GUIGetMsg() ist ein Handle
Oder sind Events kein Handle?
Ich würde sagen, dass diese Events einfach nur Konstanten sind, also normale Zahlen. -
Oft durch $nMsg gekennzeichnet. Ich denke, dass ist der Standard.
-
$nMsg verweist ja auf einen numerischen Wert.
Genau genommen ist es das ja auch, aber GUICtrlCreate... gibt ja nunmal ein Handle zurück.James Das war auch nur auf die GUIConstants bezogen. GUICtrlCreate... sind definitiv Handles.
Wie wärs mit... $vMsg?
chess
-
Nein GuiGetMsg gibt einfach einen numerischen Wert zurück. In diesem Fall geht es dabei um kein Handle. Es kann das Handle aufnehmen, gibt es aber nicht zurück. GuiCreate() gibt ein Handle zurück
-
In der AutoIt Referenz wird von ControlID gesprochen, deswegen würde ich das auch nicht als Handle bezeichnen, denn handles sind oft einfach nur pointer. Außerdem wäre dann die Bezeichnung GUICtrlGetHandle seltsam.
Ich würde $iMsg verwenden, weil das alles integer sind. -
Was?
Wenn ich ein Control erstelle, dann gibt mir dieser Aufruf die ControlID (Also das Handle) zurück (Präfix: $h).
Und GUIGetMsg() gibt die ControlID des Controls zurück, was angeklick (Oder anderweitig angesprochen) wurde. Also gibt GUIGetMsg() auch ein Handle zurück (Mal von den Events wie $GUI_EVENT_CLOSE abgesehen).Oder sehe ich da was falsch?
chess
-
Nene.
GuiGetMsg() gibt manchmal ein Handle zurück, aber immer einen numerischen Wert. Deshalb wird $nMsg genutzt, es ist sinnvoller. Du kannst nicht einfach von den Events absehen.
-
Natürlich nicht. Aber in AutoIt ist Handle ja praktisch ein eigener Datentyp (Siehe offizieller Standard, $h-Präfix [Edit: Nach der neuen Liste ist es ja $id. Trotzdem ein eigener Datentyp in AutoIt)).
Die Events dagegen sind rein numerische Werte (Integer, also $i).Damit käme für mich nur noch Variant in Frage.
Bin mal gespannt, wie darauf reagiert wird.
chess
-
Akzeptiere es doch, wenn es in den offiziellen Beispielen steht. GuiGetMsg() gibt kein Handle zurück, sondern eine Zahl, die manchmal ein Handle präsentiert. $h… gilt nur für Funktionen, die ausschließlich Handles zurückgeben, das ist der Standard.
-
Ja, ist gut, dann halt auch kein $vMsg.
chess
-
Ich würde das aber trotzdem als ID und nicht als handle bezeichnen, einfach um Verwechslungen zu vermeiden, denn mit handle werden oft die aus der WinAPI z.B. HWND, HMODULE, HANDLE, HINSTANCE bzw. die entsprechenden AutoIt-Typen bezeichnet. Handles sind oft als pointer präsent, die IDs sind aber mehr so eine Art Array-indices.
-
Zitat von chesstiger
Genau genommen ist es das ja auch, aber GUICtrlCreate... gibt ja nunmal ein Handle zurück.
Wenn man es allerdings ganz genau nimmt, sollte man aber $id für AutoIt-Controls verwenden, oder?Zitat von www.autoitscript.com/wiki/UDF-spec$h - Handle, usually to a file or window. NB: AutoIt handled controls return IDs, and so use $id instead.
$id - An AutoIt control Id.Edit: Ok, hast du ja schon editiert.
-
@DieBeidenÜberMir
Zitat von chesstiger
(Siehe offizieller Standard, $h-Präfix [Edit: Nach der neuen Liste ist es ja $id. Trotzdem ein eigener Datentyp in AutoIt)).Ist mir auch gerade eben aufgefallen.
Das ist halt der neue Coding-Standard.
Hier in diesem Turorial und auch in meinen eigenen Skripten nutze ich jedoch noch den alten Standard.Daher kommt also mein kleiner Fehler.^^
chess
-
Hatten wir auch schon. Das liegt wahrscheinlich daran, dass $h immer mehr für spezifische Fälle wie Fenster oder DCs verwendet wird. Es sollte als $hGui, aber $idButton1 heißen.
whatever
-
- Offizieller Beitrag
Da bekanntermaßen AutoIt in dieser Richtung keine Vorschriften macht, ist es aus meiner Sicht in erster Linie wichtig, dass ein Skript eindeutig lesbar ist.
Ob ich ein Control mit $id.. oder $c.. oder auch mit einem Controlbezogenen Kürzel ( $btn.., $cb.., $in.. ) beginne, ist dabei eher nebensächlich.
Aber einen Punkt sehe ich genau, wie bereits diskutiert: Ein $h.. gehört nur vor ein echtes Handle, niemals soll es für eine ID eingesetzt werden. -
Naja, das klingt schon logisch.
Allerdings meine ich, das auch irgendwo in der Hilfe mal gelesen zu haben.
Außerdem steht nach dem alten Standard nichts anderes zur Verfügung - Handle kam wohl der ControlID am nächsten.Nach dem neuen Standard steht uns jedoch - wie bereits erwähnt - $id zur Verfügung.
Ich werde dann mal in naher Zukunft das Tutorial dahingehend an den neuen Standard anpassen.chess