Script zum beheben der "Script breaking changes"

    • Offizieller Beitrag

    In der Shoutbox gab es ja heute die Diskussion über die "Script breaking changes" und das dadurch einige ältere Scripte nicht mehr laufen.

    Ich denke, bei den meisten alten Scripten müssen nur ein paar Ersetzungen vorgenommen werden. Beim durchschauen von meinen alten Scripten sind mir drei wesentliche Punkte aufgefallen:

    1. die globale GDI+ Variable (alt: $ghGDIPDll, neu: $__g_hGDIPDll).

    2. die Funktion "_IIF", die aufgrund des ternären Operators gestrichen wurde.

    3. AdlibEnable -> AdlibRegister und AdlibDisable -> AdlibUnRegister.

    Und warum alles von Hand ersetzen, wenn wir doch AutoIt haben? Also habe ich ein kleines Script geschrieben, was diese Ersetzungen vornimmt:

    Fallen euch noch weitere "Script breaking changes" ein, die man hier mit aufnehmen kann?

    Edit 30.01.18: Es gibt jetzt noch folgende Ersetzungen:

    - _StringReverse

    - OnAutoItExit

    - OnAutoItStart

    Außerdem habe ich mal ein Beispielscript im alten Stil ("test1.au3" im Anhang) geschrieben, was mit der aktuellen AutoIt-Version nicht lauffähig ist. So könnt ihr sehen, was das obige Script daraus macht und dass es danach funktioniert.

  • Hi, Oscar!

    Klasse Idee! Ich finde da bestimmt noch einiges, aber zunächst:

    Mein absoluter Favorit, das Umbenennen der Feldnamen der $TagBitmapInfo-Struct-KONSTANTEN :Face:

    vorher:

    $TagBitmapInfo="struct;dword Size;long Width;long Height;word Planes;word BitCount;dword Compression;dword SizeImage;long XPelsPerMeter;long YPelsPerMeter;dword ClrUsed;dword ClrImportant;endstruct;dword RGBQuad[1]"

    nachher:

    $TagBitmapInfo="struct;dword biSize;long biWidth;long biHeight;word biPlanes;word biBitCount;dword biCompression;dword biSizeImage;long biXPelsPerMeter;long biYPelsPerMeter;dword biClrUsed;dword biClrImportant;endstruct;dword biRGBQuad[1]"

    Was letztendlich bei mir dazu geführt hat, verstärkt die Werte, also gewissermaßen die "evil Numbers" zu verwenden. (DAS war bestimmt nicht im Sinne des Erfinders....)

    Statt

    $tBMI = DllStructCreate($tagBITMAPINFO)

    DllStructSetData($tBMI,"biWidth", $iwidth)

    also

    DllStructSetData($tBMI, 2, $iwidth) ;hier ist es völlig egal, welche Autoit-Version verwendet wird

    oder auch statt

    _WinAPI_BitBlt($DC_gui, 0, 0, 256, 256, $DC_bitmap, 0, 0, $srccopy)

    nun

    _WinAPI_BitBlt($DC_gui, 0, 0, 256, 256, $DC_bitmap, 0, 0, 0xCC0020) ;nur wegen der einen Konstanten $srccopy eine komplette UDF laden.....neeeeee^^

    Denn diese Konstanten (sic) kommen nicht aus der Autoit-Welt und/oder sitzen in irgendwelchen UDF´s, sondern werden seit Anbeginn aller Zeiten als Parameter in den M$-Funktionen verwendet.

  • Was letztendlich bei mir dazu geführt hat, verstärkt die Werte, also gewissermaßen die "evil Numbers" zu verwenden. (DAS war bestimmt nicht im Sinne des Erfinders....)

    Diesen Punkt kann ich zu 110 Prozent unterschreiben !!

    Besonders in größeren Produktivskripten sind 'evil numbers' (auch 'magic numbers' genannt) für mich ein absolutes NoGo !

    Simples Beispiel für diejenigen, die mit dem Begriff 'evil numbers' nichts anfangen können :

    Man möchte eine Messagebox erzeugen mit :
    - Buttons : Ja, Nein, und Abbrechen (3) -> $MB_YESNOCANCEL

    - Icon : Fragezeichen (32) -> $MB_ICONQUESTION

    - Zweiter Button ist Standardbutton (256) -> $MB_DEFBUTTON2

    Was ist verständlicher, wenn auch nicht gerade kürzer ^^ ? :

    MsgBox(291, "","")

    oder :

    MsgBox($MB_YESNOCANCEL + $MB_ICONQUESTION + $MB_DEFBUTTON2 , "","")

    (geht natürlich auch mit BitOR(...) )

    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

    • Offizieller Beitrag

    Besonders in größeren Produktivskripten sind 'evil numbers' (auch 'magic numbers' genannt) für mich ein absolutes NoGo !

    Jein, wenn ich mir dadurch Includes erspare, schreibe ich lieber die Zahlenwerte und im Kommentar dahinter den Namen der Konstanten (; -3 = $GUI_EVENT_CLOSE). Allerdings sicher niemals für $GUI_EVENT_CLOSE, den Wert sollte man einfach kennen. :P

    Aber btt: Sinnvolles Skript - genau das, was AutoIt hervorragend kann.

  • Jein, wenn ich mir dadurch Includes erspare, schreibe ich lieber die Zahlenwerte und im Kommentar dahinter den Namen der Konstanten

    Könntest auch den Au3Stripper nutzen, das habe ich mir angewöhnt. Oder du definerst die Konstanten oben selber ohne es zu includen, aber hast dann das Problem, dass du bei einigen UDFs die Konstanten neu deklarierst.

  • Jein, wenn ich mir dadurch Includes erspare, schreibe ich lieber die Zahlenwerte und im Kommentar dahinter den Namen der Konstanten ;) -3 = $GUI_EVENT_CLOSE). Allerdings sicher niemals für $GUI_EVENT_CLOSE, den Wert sollte man einfach kennen.

    Damit hast Du natürlich nicht unrecht. Mein Statement '... absolutes NoGo' war ggf. eine Spur zu scharf ;).

    Sofern man, als fortgeschrittener User, weiß was man macht, oder wie in deinem Beispiel die 'evil numbers' per Kommentar beschreibt, kann man sich Includes wegen einiger Konstanten in der Tat sparen.

    Trotzdem dürfte die Verwendung von Konstanten ein Skript i.A. für Einsteiger leichter verständlich machen, aber dbzgl. sind wir sicher einer Meinung ^^ .

    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

  • Wieso sollte $MB_DEFBUTTON2 mehr Aussagekraft haben als 256 ? Die Zahlen sind nicht schlechter als Variablen. Was wirklich hilft ist eine ausführliche, langfristig verständliche Beschreibung. Denn Beschreibungen - zu etwas - was man gerade geschrieben hat - sind immer verständlich - glaubt man!

    Nur Beschreibungen, die man nach 1-2 Jahren noch versteht - erfüllen den Anspruch. Das erfordert tatsächlich Übung!

    Gruß

    Peter

    Hinweise auf Suchmaschinen finde ich überflüssig - wer fragt hat es nicht gefunden oder nicht verstanden. Die Antwort gibt sich oftmals schneller als der Hinweis auf Dr. Goggle & Co.

    Ab 19-10-22 ergänzt um:

    Die Welt wird nicht bedroht von den Menschen, die böse sind, sondern von denen, die das Böse zulassen. (Albert Einstein)

  • Wieso sollte $MB_DEFBUTTON2 mehr Aussagekraft haben als 256 ?

    Gut, das war vielleicht ein nicht so einleuchtendes Beispiel aber vielleicht stimmst du ja überein, dass

    BitOR($GUI_SS_DEFAULT_GUI,$WS_SIZEBOX,$WS_THICKFRAME), BitOR($WS_EX_TOOLWINDOW,$WS_EX_WINDOWEDGE))

    verständlicher ist als 0x94CE0000, 0x00000180

    Bei MsgBoxen verwende ich auch direkt die Nummern, weil ich sie mehr oder weniger über die Jahre auswendig gelernt habe und zur Not mit dem MsgBox Wizard (Alt+W im SciTE Code) erzeuge.

  • Wieso sollte $MB_DEFBUTTON2 mehr Aussagekraft haben als 256 ? Die Zahlen sind nicht schlechter als Variablen.

    Hallo Peter !

    Technisch gesehen sind Zahlen natürlich nicht 'schlechter', sie bewirken ja das selbe. Trotzdem denke ich schon, dass Konstanten eine höhere Aussagekraft besitzen als ein nummerischer Wert !

    Bei MsgBox($MB_YESNOCANCEL + $MB_ICONQUESTION + $MB_DEFBUTTON2 , "","") weiß man sofort worum es geht, bei 291 nicht unbedingt, und das ist ja nur ein Bruchteil der möglichen Kombinationen.

    Natürlich kann man, wie BugFix schrieb, hinter den Funktionsaufruf auch einen Kommentar schreiben. Generell haben Konstanten aber ihre Existenzberechtigung, besonders bei weniger gebräuchlichen Funktionen. Letztlich soll es aber jeder so machen, wie er möchte ;).

    Edit : alpines

    Ich habe das 'simple' Beispiel der MsgBox gewählt, damit es auch für Einsteiger und Gäste leicht nachvollziehbar ist.

    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

    Einmal editiert, zuletzt von Musashi (30. Januar 2018 um 09:00)

  • Bei MsgBox($MB_YESNOCANCEL + $MB_ICONQUESTION + $MB_DEFBUTTON2 , "","") weiß man sofort worum es geht, bei 291 nicht unbedingt, und das ist ja nur ein Bruchteil der möglichen Kombinationen.

    Deshalb mache ich das meistens so, dass ich nicht die Summe, sondern die einzelnen Flags als Addition hinschreibe. Zum Beispiel: 48 + 4

    Letzen Endes ist es Stilsache, es benennen ja auch nicht alle ihre Variablen mit der ungarischen Notation :)

    • Offizieller Beitrag

    Mein absoluter Favorit, das Umbenennen der Feldnamen der $TagBitmapInfo-Struct-KONSTANTEN

    Hmm..das wird aber schwierig zu automatisieren.

    Man müsste ja erstmal rausfinden, ob es sich bei der Strukturvariablen um eine $tagBITMAPINFO-Struct handelt und wenn die Deklaration in einer Includedatei stattfindet, wird es richtig eklig.

    Und dann ist $tagBITMAPINFO ja auch noch unterteilt. Sie besteht ja zum Teil aus $tagBITMAPINFOHEADER (die Felder dieser Konstante müsste man auch korrigieren).

    Da habe ich gerade keinen Lösungsansatz. :/

  • Wieso sollte $MB_DEFBUTTON2 mehr Aussagekraft haben als 256 ?

    Eine Magic Number geht ja meist problemlos.

    Aber:
    305 statt $MB_OKCANCEL + $MB_ICONWARNING + $MB_DEFBUTTON2

    für das Flag bei msgBox wird unleserlich.
    Konstanten dokumentieren daher viel besser als eine einzige Zahl.


    Vergesst den Beitrag! Das wurde ja oben schon mehrfach behandelt. Sinnerfassendes und vollständiges lesen des Threads hätte geholfen 8)

    • Offizieller Beitrag

    Etwas, was noch nicht erwähnt wurde, sind die "Script breakings changes" bei den genannten Konstanten.

    Wenn beispielsweise die Konstante $GUI_EVENT_CLOSE mal irgendwann von dem Wert "-3" auf "-4" geändert wird, dann laufen sehr viele Scripte nicht mehr.

    Die Verwendung der Konstanten hat also auch etwas mit der Lauffähigkeit des Scripts in der Zukunft zu tun, weshalb ich eigentlich immer die Konstanten (nicht die Werte) verwende.

    Sehr verärgert bin ich darüber, wenn sich die Konstante selbst ändert. Siehe $ghGDIPDll in $__g_hGDIPDll, was zu vielen Problemen geführt hat.

  • Wenn beispielsweise die Konstante $GUI_EVENT_CLOSE mal irgendwann von dem Wert "-3" auf "-4" geändert wird, dann laufen sehr viele Scripte nicht mehr.


    Sehr verärgert bin ich darüber, wenn sich die Konstante selbst ändert.

    Ist es in der Vergangenheit schon häufiger vorgekommen, dass der Wert einer Konstante geändert wurde ?

    Ich habe das Changelog von UEZ nur kurz überflogen, konnte ja nicht ahnen, dass es nach 30 min. weg ist.

    An zumindest eine als 'script breaking change' gekennzeichnete Änderung einer Konstante kann ich mich aber grob erinnern : Irgendetwas mit xxxPusxxx wurde zu xxxPushxxx geändert (Tippfehlerbeseitigung).

    Kein sauberer Stil, aber wäre es hier nicht sinnvoll, beide Konstanten mit gleichem Wert zu behalten ?

    UEZ : Könntest Du das MVP-Changelog bitte erneut posten, oder wird man dafür wegen Verrats in die Wüste geschickt :/?

    Vergesst den Beitrag! Das wurde ja oben schon mehrfach behandelt.

    Lustig, dass auch Du die MessageBox als Beispiel für die Vorteile von Konstanten verwendet hast ^^.

    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

    • Offizieller Beitrag

    Ist es in der Vergangenheit schon häufiger vorgekommen, dass der Wert einer Konstante geändert wurde ?

    Nein! Oder zumindest nicht, dass ich mich erinnern kann.

    Von daher spricht das eher für die Benutzung der Werte, das gebe ich zu. :S8)

    Wenn man aber die bessere "Lesbarkeit" mit in die Waagschale wirft, dann doch eher die Konstanten. ;)

    Edit: Achso, ich wollte doch noch erwähnen, dass es eine neue Version gibt (Post#1).

  • Von daher spricht das eher für die Benutzung der Werte, das gebe ich zu. :S8)

    Wenn man aber die bessere "Lesbarkeit" mit in die Waagschale wirft, dann doch eher die Konstanten. ;)

    Ich weiß jetzt nicht, ob ich deine Smileys richtig interpretiere, daher noch mal zur Sicherheit ;) :

    Ich plädiere ausdrücklich für die Verwendung von Konstanten anstelle von 'magic numbers':!:

    Gruß Musashi

    P.S. Könnte mal bitte jemand gelbe Smileys für :!::?:und <3 einführen, das sieht ja furchtbar aus ^^

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

  • alpines

    Die Idee hatte ich auch noch nicht das in Summe der einzeladditionen zu schreiben -- > mache ich zukünftig so --> ist übersichtlicher :)

    Also scribt breaking changes haben bei mir schon für Arbeit gesorgt. Die Verschlüsselung war mal an der Reihe, Irgendwie habe ich auch noch was mit den öffnen von Dateien in Erinnerung - das dann auf Binär umgestellt wurde.... usw.

    Machmal frage ich mich ob die neue Version das Wert ist :)

    Gruß

    Peter

    Hinweise auf Suchmaschinen finde ich überflüssig - wer fragt hat es nicht gefunden oder nicht verstanden. Die Antwort gibt sich oftmals schneller als der Hinweis auf Dr. Goggle & Co.

    Ab 19-10-22 ergänzt um:

    Die Welt wird nicht bedroht von den Menschen, die böse sind, sondern von denen, die das Böse zulassen. (Albert Einstein)

  • Also... Generell sind Magic Numbers erstmal schlecht. Per se lässt sich ein Skript mit sprechenden Konstanten wesentlich schöner lesen. Allerdings kann es u.U. einfach angenehmer sein, direkt die Zahl zu schreiben. Und mit einigen Jahren Programmiererfahrung (besser: AutoIt- und Win32-Erfahrung) _weiß_ man halt einfach etliche Konstanten auswendig. Die bereits genannte -3 für GUI_EVENT_CLOSE ist fast jedem bekannt und wenn nicht durch den Kontext trotzdem schnell zuordbar. Da ist das in Ordnung, finde ich.

    Und ehrlich gesagt gibt es auch einige Bereiche, die in AutoIt nicht durch Standard-Konstanten abgedeckt sind. Die meisten Errorcodes bspw. haben keine äquivalente Konstante. Oder -1 für das letzte Control bei GUI-Befehlen. Ist streng genommen auch eine Magic Number.

    Zusammengefasst finde ich, dass man in vernünftigen Mengen durchaus Literale statt Konstanten verwenden kann. Solange man nicht die Übersicht verliert.

  • Die Verwendung von Konstanten erspart einem aber auch oft sehr viel Zeit bei der Suche nach Fehlern und es ist meist auch auf dem ersten Blick erkennbar, wenn falsche Werte verwendet verwendet werden. Bei einer Magic Number kann ich mich schnell mal vertippen oder auch verrechnen... chesstiger hat das sehr schön formuliert.

    Ich denke: Je wichtiger/gefählicher die Funktion, umso sparsamer sollte man mit Magic Numbers hantieren.