UDF funzt nach Autoit - Update nicht mehr

1. offizieller Beitrag

    Hallo zusammen,

    ich arbeite an einem script, dass u.A. die Funktioni _ExcelBookOpen und $MB_TOPMOST aus den MsgBoxConstants.au3 nutzt bzw nutzen soll.
    Die Handhabung von Excel hat bereits einwandfrei funktioniert.
    Dann wollte ich $MB_TOPMOST nutzen ... dabei bekam ich eine Fehlermeldung.

    Google sagte mir dann, dass ich Auto-it mal updaten sollte.
    Also ersetzte ich meine v3.3.8.0 (glaube ich) durch v3.3.12.0 ...

    Wenn ich jetzt das script starte, bekomme ich die Meldung ...

    Code
    "\\scripting\autoSL\autoSL.au3" (52) : ==> Unknown function name.:
Local $oExcel = _ExcelBookOpen($SLfile)
Local $oExcel = ^ ERROR

    Was ist denn da passiert ... hab keine Ahnung, wo ich da mit der Fehlersuche ansetze ;(

    Für Hilfe wäre ich dankbar ...

    Cappy

    AutoIt 3.3.12.0 // SciTE 3.4.4 // Sublime Text 2 AU3 language package 1.3.6

    Die Excel-UDF wurde komplett umgeschrieben.
    Die Funktion _ExcelBookOpen() gibt es z.B. nicht mehr - heißt jetzt stattdessen: _Excel_BookOpen().
    Das verursacht bei dir den Fehler.
    Aber auch so wirst du einiges umschreiben müssen.
    Ohne Hilfe dazu lesen wird es nicht gehen.

    Huhu,

    bedeutet aber für den gelegentlichen Scipter, dass man ziemlich ins Dilemma rutscht ... :(

    nicht gut.

    Cappy

    P.S: kann mir in dem Zusammenhang denn Jemand erklären, wie _Excel_ReadSheetToArray jetzt heißt ???

    AutoIt 3.3.12.0 // SciTE 3.4.4 // Sublime Text 2 AU3 language package 1.3.6

    Über die Online-Docu von AutoIt gelangst Du zu "History / Changelog". Dort steht ganz am Anfang der Link zu den Script Breaking Changes.
    Dort siehst Du dann, was sich zwischen der alten und der neuen Funktion geändert hat. Über den Eintrag zur Excel UDF findest Du dann die
    folgende Seite mit einer genauen Auflistung was sich geändert hat.

    BTW:
    Warum das Excel UDF komplett neu geschrieben wurde, wird hier beschrieben.

    Wieso gibt es seitens AutoIt eigentlich keine Funktion, um diese "alten" UDF´s (die immerhin zusammen mit AutoIt ausgeliefert werden) direkt per Hinweis mit den "neuen" zu ersetzen?
    Und die Funktionen im Script gleich mit....
    Dann könnte man sich diesen und zig weitere Threads zu diesem Thema komplett sparen. Und die Aufgabe, teilweise hunderte von Scripten händisch umzuschreiben (und das ggf. beim nächsten Update wieder ! ) würde sich auf einige Mausklicks reduzieren.

    Ernsthaft?

    Ja, ernsthaft!
    Mal abgesehen davon, dass es absolut keinen Grund für scriptbreaking changes in UDF´s gibt (man sollte mal hinterfragen, wieso das User Defined Functions genannt wird! ) wäre es wenigstens sinnvoll, die "bisherigen", sehr gut funktionierenden UDF´s mit dem ursprünglichen Namen mit in die aktuelle AutoItversion zu packen.

    Gerade du müsstest es am allerbesten wissen! Wie oft hast du im letzten halben Jahr auf Threads wie diesen antworten müssen, obwohl die Scripte der User bisher einwandfrei funktioniert haben!?
    Ich habe ja garnichts gegen "neue" und wegen mir auch "bessere" UDF´s, aber die sollen dann bitte schön auch entsprechend gekennzeichnet sein, so dass ICH als USER mir aussuchen kann, ob ich ein Script einfach nur (mit "alten" Funktionen) benutzen kann, oder mir die Mühe mache, alles umzuschreiben.
    Zur Zeit ist es so, dass bestehende Unterverzeichnisse mit den darin befindlichen UDF´s einfach von einer neueren Version überbügelt werden. Woher soll der 08/15-User wissen, welche der "alten" UDF´s bzw. Funktionen von seinen Scripten gebraucht bzw. so weit benötigt werden, dass das Script nicht nur anstandslos funktioniert, sondern auch die erwarteten Ergebnisse liefert?

    Stell dir vor, du arbeitest mit einer Branchensoftware FIBU-SOFT, welche regelmäßig mit Updates versorgt wird. Das ist heutzutage die Regel! Eines Morgens machst du den Rechner an und hunderte deiner Kollegen auch. Auf allen Bildschirmen erscheint
    ""\\software\FIBUSOFT\FIBU_SL.sqn" (52) : ==> Unknown function name.:
    Local $oFIBUSOFT = _FIBUSOFTOpen($SLfile)"
    Du rufst die Hotline des Softwareherstellers an und fragst, was da los ist. Als Antwort bekommst du:

    Zitat von helpdesk

    Über die Online-Docu von FIBU-SOFT gelangst Du zu "History / Changelog". Dort steht ganz am Anfang der Link zu den Script Breaking Changes.
    Dort siehst Du dann, was sich zwischen der alten und der neuen Funktion geändert hat. Über den Eintrag zur FIBU-SOFT Bibliothek findest Du dann die
    folgende Seite mit einer genauen Auflistung was sich geändert hat. (qed in Anlehnung an dein Post #7)

    Und keine Angst, wenn die bisher von Ihnen erfassten Aufträge nicht mehr lesbar sein sollten, ändern Sie einfach folgende Datenfeldinhalte wie beschrieben ab...blablub

    Eins kann ich dir schwören, dieser Fall tritt so NIE ein, denn keine Firma kann sich so etwas leisten!
    Als Admin führst du dieses Gespräch auch garnicht, sondern stößt sofort ein Rollback an, direkt gefolgt von der Inrechnungstellung desselben!
    Oder was würdest du in diesem Fall machen?

    • Offizieller Beitrag

    Ich sehe ein Hauptproblem darin, dass sich bisher niemand die Mühe gemacht hat, neue Funktionen so zu schreiben, dass diese alle Parameter an der selben Position führen und evtl. zusätzliche Parameter bei Nichtbeachtung automatisch zu einem Fallback auf die Vorversion führen. DAS wäre mal ein sinnvoller Beitrag um Script Breaking Changes zu unterbinden.
    Analog dazu wäre es sinnvoll nicht mehr vorhandene Funktionen über verlinkende Aufrufe auf die neue Funktion umzuleiten.

    Zitat von Andy

    Mal abgesehen davon, dass es absolut keinen Grund für scriptbreaking changes in UDF´s gibt

    Wie kommst Du auf die Idee, dass es absolut keinen Grund dafür gibt? Ich nehme mal an, dass Du das engl. Forum und die Diskussion über die Aktualisierung der Excel UDF nicht verfolgt hast. Selbstverständlich habe ich versucht, eine abwärtkompatible Version zu erstellen. Ging aber nicht, da die Änderungen an den Konzepten um bessere Performance, die Einbindung der Funktionalität neuer Excel-Versionen und die Beseitigung von Ungereimtheiten zu erreichen, nicht sinnvoll in einer UDF abzuhandeln waren.

    Zitat

    Gerade du müsstest es am allerbesten wissen! Wie oft hast du im letzten halben Jahr auf Threads wie diesen antworten müssen, obwohl die Scripte der User bisher einwandfrei funktioniert haben!?

    Kein Problem. Damit habe ich gerechnet und daher beobachte ich auch die Foren nach solchen Anfragen.

    Zitat

    Ich habe ja garnichts gegen "neue" und wegen mir auch "bessere" UDF´s, aber die sollen dann bitte schön auch entsprechend gekennzeichnet sein, so dass ICH als USER mir aussuchen kann, ob ich ein Script einfach nur (mit "alten" Funktionen) benutzen kann, oder mir die Mühe mache, alles umzuschreiben.

    Der User kann ja zwischen mehreren Möglichkeiten entscheiden: Auf der alten AutoIt-Version bleiben, seine Skripte kompilieren oder die UDFs aus der alten Version in das User-Include-Verzeichnis kopieren etc.
    Was auf jeden Fall hilft: RTFM. Nur auf den Install-Button klicken weil es gerade eine neue Version gibt, führt manchmal zu Kopfschmerzen.

    Zitat

    Oder was würdest du in diesem Fall machen?

    Eine saubere Migrationsplanung!
    In unserem Unternehmen wird nicht ungeplant eine neue Version eingespielt, sondern zuerst brauchst Du einen use case der das Update rechtfertigt. Dann wird mal die Doku konsultiert um die Änderungen festzustellen und den Migrationsaufwand abzuschätzen. Dann wird getestet und erst wenn das alles funktioniert hat, dann roll man das Update aus.
    Ein Upgrade bei dem am nächsten Tag hunderte Kollegen nicht arbeiten können, führt zu erheblichem Erklärungsbedarf der Verantwortlichen. Das ist einfach kein professionelles Vorgehen!