Fehler bei Script mit DBF-UDF

  • Moombas (nur um etwaigen Missverständnissen vorzubeugen) :

    FileInstall bindet Dateien wie Grafiken oder hier eine .dll in das Skript ein, und extrahiert sie beim Programmstart in das angegebene Verzeichnis. Sie ist danach also als eigenständige Datei vorhanden, so, als ob Du sie 'normal' beigelegt hättest.

    Dies unterscheidet sich von einem #include, bei dem die inkludierte UDF ein Teil des Hauptskriptes wird !

    Wobei, WENN man schon mit einer DLL arbeitet, man diese auch so in ein Script "einbauen" kann, dass diese im Scriptablauf direkt in den Speicher geladen und angesprochen werden kann, OHNE den Umweg über ein Speichern in den Verzeichnispfad (und Starten von dort aus).

    ICH versehe diese DLL dann mit einem auf das Script angepassten Namen.

    Sicherlich kann man auf dem Standpunkt stehen, dass eine per Fileinstall eingebundene DLL, welche vom Script beim ersten Start in den Scriptordner geschrieben wurde, problemlos durch eine andere (ggf. "neuere") Version dieser DLL ersetzt werden könnte.

    Der Sinn einer DLL liegt aber darin, nur EINMAL in den Speicher geladen werden zu müssen, und ALLE anderen Programme haben dann Zugriff auf die in der DLL enthaltenen Funktionen. Ob das bei einer DLL Sinn macht, die Betriebssystemweit (mit der neueren Version ja "geänderte") Datenbankfunktionen bereit stellt, ist Ansichtssache.

    Was habe ich denn gemacht, nachdem es gelaufen hatte ... (Brainstorming) ...

    *snip*
    [......MASSIVES BRAINSTORMING....].

    *snip*


    Und dennoch muss sich ja irgend etwas geändert haben ... <Haare rauf´>

    Im Extremfall muss "nur" über irgendein Update eine geänderte Version eingespielt werden, und es ergeben sich die seltsamsten "Probleme". Die mit dem eigentlichen AutoIt-Script aber auch garnichts (!) zu tun haben...

    Wenn man eine langfristig funktionierende Version eines Scripts mit einer (nur dafür) benutzten DLL haben möchte, dann sollte man den Namen dieser DLL entsprechend an das Script anpassen.

    Und wer meint, "soooo schlimm" kann es nicht kommen, der sei auf den aktuellen Thread zum Thema "MsgBox verlangsamt den Skriptablauf unter Win 10" verwiesen....dort wurde nämlich auch NUR eine Funktion (PeekMessage) innerhalb einer systemweit verwendeten DLL (user32.dll) geändert....

  • Und wer meint, "soooo schlimm" kann es nicht kommen, der sei auf den aktuellen Thread zum Thema "MsgBox verlangsamt den Skriptablauf unter Win 10" verwiesen....dort wurde nämlich auch NUR eine Funktion (PeekMessage) innerhalb einer systemweit verwendeten DLL (user32.dll) geändert....

    Wenn Andy's obige Aussage der Tatsache entspricht, sollte es aber auch möglich sein, dieser Verlangsamung aus dem Wege zu gehen,

    indem man Autoit irgendwie dazu zwingen könnte eine ältere Version der "user32.dll" zu verwenden die im Autoit-Pfad liegt.

    Kann ich leider nicht testen, da ich "Gott sei Dank" noch kein Win 10 benutzen muss.

    Dann kann man sich das patchen von Autoit sparen.

    Dann testet doch mal diesen Weg.

    MfG Tuxedo

    ps:

    Da der Beitrag besser in den Thread zum Thema "MsgBox verlangsamt den Skriptablauf unter Win 10" pssen würde,

    wäre es gut wenn ein Mod oder Admin den Beitrag dorthin verschieben könnte.

    Ich konnte ihn mit Andys Zitat leider nur hier erstellen und nachträglich dorthin kopieren ging eben falls nicht, Danke Tuxedo

    Einmal editiert, zuletzt von Tuxedo (3. Mai 2020 um 10:12)

  • Wobei, WENN man schon mit einer DLL arbeitet, man diese auch so in ein Script "einbauen" kann, dass diese im Scriptablauf direkt in den Speicher geladen und angesprochen werden kann, OHNE den Umweg über ein Speichern in den Verzeichnispfad (und Starten von dort aus).

    Ich weiß, wollte aber diesen Punkt nicht noch zusätzlich in's Spiel bringen ;).

    Gleichwohl ist das eine nützliche Info für alle, die es nicht wissen.

    Mit den systemweiten .dll's ist das wirklich so eine Sache.

    Folgendes Szenario ist mir z.B. schon häufiger untergekommen :

    -> Programm A installiert die VC Runtimes über die entsprechenden Installer (z.B. vcredist_x86.exe und vcredist_x64.exe). Danach sind sie systemweit für alle Programme verfügbar - so soll es ja auch sein.

    -> Programm B, welches die Runtimes ebenfalls benötigt, stellt bei der Installation fest, dass diese bereits vorhanden sind und nicht erneut installiert werden müssen (genauer, die vcredist_x*.exe machen das).

    -> Programm A wird mittels eines (schlecht geschriebenen) Uninstallers deinstalliert, inkl. der Runtimes.

    ==> Programm B steht nun im Regen !

    Soweit ich weiß (lasse mich aber gerne korrigieren), sucht eine .exe benötigte .dll's zuerst im eigenen Verzeichnis. Um das obige Szenarion zu entschärfen, packen daher viele Programme die Runtime-dll's (z.B. msvcp140.dll und vcruntime140.dll) noch mal gesondert in z.B. das \bin Verzeichnis.

    Das ist natürlich nicht im Sinne des Erfinders, aber was soll's :(.

    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."

  • Programm A installiert die VC Runtimes über die entsprechenden Installer

    omfg....da erwischst du das absolute Paradebeispiel! Ich ergänze zu:

    -> Das nur sporadisch genutzte Programm A installiert die VC Runtimes in der Version xxxx

    -> Das ebenfalls nur sporadisch genutzte Programm B, welches die Runtimes ebenfalls benötigt, stellt bei der Installation fest, dass die Version yyyy benötigt wird und installiert diese.

    -> Programm A, nach Tagen/Wochen gestartet, besteht auf die VCR in der Version xxxx und bietet (Heureka!) den Download dieser Version an...

    -> Programm B, nach Tagen/Wochen gestartet, besteht auf die VCR in der Version yyyy bietet (Heureka!) den Download dieser Version an...

    -> Programm A, nach Tagen/Wochen gestartet, besteht auf die VCR in der Version xxxx und bietet (Heureka!) den Download dieser Version an...

    -> Programm C, nach Tagen/Wochen gestartet, besteht auf die VCR in der Version zzzz und bietet (Heureka!) den Download dieser Version an...

    ==> Der Anwender steht nun im Regen !

    Ich hatte genau dieses Szenario vor einigen Jahren, schlimm wurde es dann, als Programme nicht mehr mit dem Hinweis starteten, dass eine VERALTETE Version der Runtime vorliegt, und doch bitte eine "aktuelle" Version installiert werden sollte.


    Wer jetzt meint, das sei ein schlechter Scherz, dem sei der Abschnitt "Die Ch*p Redaktion rät" aus folgendem LINK ans Herz gelegt, da bleibt einem das Lachen im Hals stecken....

    Und was hat das jetzt mit dem Topic zu tun?

    "Plötzlich" auftretende Fehler bzw. nicht mehr funktionierende Programme müssen nicht ursächlich mit dem Programm/Anwendung zu tun haben.

    Daher rate ich bei "selbstgestrickten" Anwendungen (und AutoIt-Scripte fallen da auch drunter) dazu, die benötigten (im speziellen DB-) Funktionsbibliotheken aka DLL´s umzubenennen. Bei heutigem RAM-Ausbau sind die Handvoll zusätzlich verbratenen Bytes im Speicher irrelevant...

    Die Stunden vor dem Rechner (und in diversen Foren) bei der Fehlersuche/analyse sind in anderen Tätigkeiten besser investiert.