Beiträge von BugFix

  • Guis Buggen in einander

    Zitat von autoBert

    das Beispiel aufzuHübschen

    ;) Was stellst du dir darunter vor?

    Es ist ein Bsp. zu einer konkreten Konstellation, somit nicht direkt für eine allgemeingültige UDF nutzbar.

    Aber was am Inhalt verbessert werden kann:

    - Array-Funktionen sind nicht nötig. Die Anzahl der Elemente sind bekannt, das Array kann somit mit erforderlicher Zahl deklariert und per Indexierung belegt werden.

    - Speichern der Ctrl-Namen ist nicht erforderlich, kann bei Bedarf über die ID abgefragt werden (s. hier: GuiCtrlInfo.au3)

    - Ich würde z.B. ein gemeinsames 2D-Array für hWnd und ID führen: [[hWnd_1,ID_1], [hWnd_1,ID_2],..,[hWnd_1,ID_n],[hWnd_2,ID_1], [hWnd_2,ID_2],..,[hWnd_2,ID_n]] , aber das ist Geschmackssache

  • Robocopy

    Danke, da werde ich mal probieren. :thumbup:

  • au3-2-exe

    Zitat von Alina

    ! ! Es ist kein AutoIt auf dem PC wo die Exe erstellt werden soll. ! !

    Warum dann die EXE? Kompiliere dir irgendeine funktionslose Alibi-AutoIt.exe. Dann kannst du als Parameter jede *.au3 ausführen, sofern diese keine zusätzlichen Includes braucht.

    Zitat von AutoIt Hilfe
    Code
    Run a script using another compiled script:

Compiled.exe [/ErrorStdOut] /AutoIt3ExecuteScript file [params ...]
                Execute another AutoIt script file from a compiled AutoIt3 executable. 

Compiled.exe [/ErrorStdOut] /AutoIt3ExecuteLine "command line"
                Execute one line of code as with AutoIt3.exe above. 

This means that there is no need to have a copy of AutoIt3.exe in addition to the compiled file - the interpreter stub of the compiled file will replace it.  So as long as there is at least one compiled script available, other AutoIt scripts can be run without the need to have AutoIt3.exe on the machine., either pre-installed or added via FileInstall.

  • Status von Fingerabdruckscanner (Windows Hello) ermitteln

    Zitat von igillan

    Hallo, gibt es eigentlich in Auto-IT die Möglichkeit den Status (erkannt oder nicht erkannt) des Fingerabdruckscanners, welcher bei der Anmeldung mit Windows

    Ich habe ein Notebook, bei dem ich statt Start-Button drücken, den Finger über den Scanner ziehe. Dann fährt das Notebook hoch und der LogIn erfolgt. Also alles jenseits von der Betriebssystem-Ebene und somit für AutoIt unerreichbar.

  • Guis Buggen in einander

    Zitat von Floooooo24

    es müsste doch ausreichen, wenn ich das selbst in meinem Code mache richtig?

    Ja, vor dem Aufruf der UDF-Funktion und danach zurück. Ob der Fehler darin begründet liegt ist nur eine Vermutung, aber du kannst zumindest weiter eingrenzen.

    Was natürlich auch sein kann:

    Du verwendest für deine Ctrl x und y und für Breite u. Höhe nimmst du die Default-Werte. DAS ist immer eine schlechte Idee, da du dann keine Ahnung hast, welche Dimensionen deine Ctrl verwenden und ob sie nicht auch über den Fensterrand hinausragen.

  • Guis Buggen in einander

    Zitat von Floooooo24

    _Metro_CreateButton

    Ich kenne die Funktion nicht, vermute aber mal in der Richtung den Fehler.

    Wenn das Erstellen von Control in eine Funktion ausgelagert wird, die selbst das Handle des Fensters anfordert, für das sie aktiv werden soll (ist ja sinnvoll), muss gewährleistet werden dass in der Funktion Folgendes zu finden ist:

    AutoIt
    Func _CreateCtrl($hGui,.....)
    Local $hOld = GuiSwitch($hGui)
    ...
    ...
    GuiSwitch($hOld)
EndFunc

    Nur so ist gewährleistet, dass die Control auch sicher auf dem gewünschten Fenster erstellt werden.

  • Robocopy

    Ich möchte für mein Backup zukünftig auf Fremdsoftware verzichten und das lieber mit systemeigener Software realisieren.

    Da robocopy an Bord ist, möchte ich dieses nutzen.

    Verstehe ich folgenden Parameter richtig:

    Code
    /mon:<n>    Überwacht die Quelle und wird erneut ausgeführt, wenn mehr als n Änderungen erkannt werden.

    Also:

    robocopy wird einmalig gestartet (z.B. händisch, aber als Admin) und dümpelt dann immer im Hintergrund bis n Änderungen vorhanden sind, um sich dann selbst neu zu starten? Ich kann dann den User abmelden (PC bleibt an) und brauch dafür keinen Task anlegen?

    Code
    /mir    Spiegelt eine Verzeichnisstruktur (entspricht /e plus /purge). Mit dieser Option mit der Option /e und einem Zielverzeichnis überschreibt die Zielverzeichnissicherheitseinstellungen.

    Während ohne /mir neue Dateien hinzugefügt oder geänderte überschrieben werden, werden jetzt an der Quelle nicht mehr vorhandene Dateien auch auf dem Ziel gelöscht. - Korrekt?

    Eine weitere Frage.

    Gibt es eine Möglichkeit, störungs- und verlustfrei eine in Betrieb befindliche SQL-Datenbank (Firebird) mit robocopy zu sichern? Die Sicherung erfolgt zwar täglich, aber sollte im Tagesverlauf mal ein Crash passieren, sind halt die Daten dieses Tages noch nicht gesichert. Und solange z.B. Aufträge noch nicht erledigt und als Lieferscheine in Papierform vorliegen, wäre eine Rekonstruktion schwierig bis unmöglich. Ist zwar in den letzten 20 Jahren nie passiert, aber man kennt ja die Pferde vor der Apotheke. ^^

    Ein reines Kopieren über den Explorer klappt nur, wenn nicht gerade ein Nutzerzugriff erfolgt. Die Quelle wird nicht kompromittiert, aber die Sicherung ist unter Umständen fehlerhaft. Das zugehörige Backuptool stoppt erst die Dienste ("Firebird Guardian" und "Firebird Server") und führt dann das Backup durch. - Kann ich natürlich im laufenden Betrieb nicht tun.

    Danke schon mal für die Mühe, die ich euch gemacht habe. ;)

  • Lesen

    [Kann ich mir nicht entgehen lassen]

    Zitat von Alina

    Sogar die Folie die extra für den Transport noch mal um die Bücher gebunden wurde war zum Teil geöffnet und mit Zollaufkleber wieder zugeklebt.

    Mit E-Books wäre das nicht passiert. :rofl:

  • Der Stumpfsinn der Gewohnheit - oder - Weil man das immer so macht.

    Zitat von Andy

    du bist einer der wenigen "Programmierer" (aka Menschen überhaupt) die ich kenne, die ihren Arbeitsablauf rekapitulieren, analysieren, nach Verbesserungen suchen und diese umzusetzen versuchen.

    Vielen Dank für die   :) .

    Ich kann nicht mal erklären, warum das so ist, aber irgendwie bin ich (mit wenigen Ausnahmen, z.B. QRCodeCreator) nie wirklich zufrieden mit dem Ergebnis. Dadurch gucke ich ab und an mal über alte Skripte drüber und prüfe, ob mit dem Wissen, das man ja immer weiter ansammelt, noch Verbesserungen drin sind. Ist vielleicht auch ein wenig meiner Arbeit geschuldet. Im Qualitätsmanagement gibt es eine Validierungspflicht für Software, d.h. alle 3 Jahre nehme ich mir für alle genutzte Software deren Einsatzbeschreibung vor (Was soll gemacht werden? Welcher Aufwand ist erforderlich? Wird das Ziel erreicht? Sind Verbesserungen möglich/erforderlich?). Das prüfe ich und wenn alles OK ist kommt ein Haken dran und 'Validierung unverändert gültig'. Werden Änderungen im Prozess notwendig, wird entsprechend neu validiert.

    Das ist wirklich sinnvoll, denn im Abstand von 3 Jahren blickt man aus einem anderen Winkel auf die Prozesse und u.U. haben sich ja auch Randbedingungen geändert, die man berücksichtigen muss.

    Zitat von Velted

    besteht der 'Stumpfsinn' für mich eher in der Tatsache, dass man nach wie vor 'Workarounds' braucht

    Das ist nicht von der Hand zu weisen. Da wir es aber nicht beeinflussen können, ist das ein Punkt, der mich nicht mehr zur Weißglut treibt.

    In meinen eigenen Skripten packe ich diese Workarounds manchmal in "Pseudo-Makro"-Funktionen, ist aber ein rein optisches Kaschieren der dafür genutzten Funktion, programmiertechnisch nicht zwingend ein Mehrwert. Für o.a. Bsp. sieht das dann so aus:

    Was Änderungswünsche im nativen AutoIt angeht - da könnten wir sicher ganze Bände mit füllen - aber: Es is, wie es is! ;)

  • Number in String

    Zitat von hpb

    und beginne noch mal von vorne.

    Ein Tipp:

    Schildere NICHT wie DU es machen möchtest - das ist die Ursache des oft zitierten XY-Problems.

    Gehe absolut neutral, gewissermaßen als Außenstehender, an die Sache heran und liste auf

    - Ausgangssituation (Datenlage etc.)

    - Zielsituation

    - zu beachtende Randbedingungen

    Dann sind Lösungsvorschläge möglich, die u.U. überhaupt nichts mit deinen Gedankengängen zu tun haben, aber effektiv zur Lösung führen.

  • Number in String

    hpb

    Also hier zeigt sich ein Kommunikationsproblem. Du kommst mit immer neuen Bedingungen um die Ecke. Das lässt eine saubere Lösung gar nicht zu.

    Definiere bitte bis zum Ende deiner geplanten Arbeitskette alle Operationen. Nicht das wieder nach Lösung eines Problems das Problem erweitert wird.

    Und nochmal in der Hoffnung das du es verinnerlichst: Wenn du FileGetAttrib verwendest ist FileExists sinnlos!!

    DARUM:

    AutoIt
    Func _Bla($_path)
    Local $sAttrib = FileGetAttrib($_path)
    If @error Then Return ; --> Ordner existiert nicht !!!
    ; ...

  • Number in String

    Zitat von hpb

    And Ergebnis von $sNewDate Then

    ????

    Du solltest dich mal entscheiden, wie deine Ordner nun tatsächlich heißen, "E:\Test" oder "...\2022-02-06".

    Ich vermute, dass du die Attributprüfung auf den Ordner "Datum" durchführen möchtest, dann brauchst du doch das Geschwurbel davor nicht.

    1. Mit _DateAdd den gewünschten Ordnernamen generieren

    2. Mit FileGetAttrib diesen Ordner auf die gewünschten Attribute prüfen, was automatisch die Prüfung auf dessen Existenz beinhaltet! FileExists ist überflüssig!

  • Suche Ordner

    Zitat von hpb

    Das ist die Lösung, die mir auch bei weiteren Abfragen helfen wird.

    Wie allerdings Bitnugger völlig richtig bemerkte, ist FileExists hier überflüssig, da FileGetAttrib nur dann ein Ergebnis liefert, wenn der Pfad existiert. Die Abfrage ist also doppelt gemoppelt. ;)

  • Der Stumpfsinn der Gewohnheit - oder - Weil man das immer so macht.

    Als ich gerade ein altes Skript von mir aktualisiert habe, ist mir aufgefallen, wie man doch ohne Nachzudenken "übliche Verfahrensweisen" ohne diese zu hinterfragen einfach übernimmt.

    Wenn wir uns die UDF für nicht-native Control ansehen fällt auf, dass ausnahmslos alle UDF, die intern das parent or owner window benötigen, dieses als Parameter in der _Create-Funktion anfordern.

    Da ich das in den UDF so gesehen habe, habe ich das auch für meine Skripte ohne zu hinterfragen übernommen.

    Jedenfalls bis ich das o.a. Skript überarbeitet habe. Ellenlange Parameterangaben in Funktionen sind dem Handling nicht gerade zuträglich. Deshalb habe ich nach Optimierung gesucht und dieses war das Parent-Handle: Es ist sinnfrei dieses anzufordern!

    Warum? - Es gibt nur 2 Situationen der Control-Erstellung:

    1. GuiCreate() wurde aufgerufen und ich erstelle nachfolgend Controls

    2. GuiSwitch() wurde aufgerufen und ich erstelle nachfolgend Controls

    In beiden Fällen befinde ich mich im Kontext des Parent/Owner-Window. Somit kann ich es bei meiner Control-Erstellung in einer UDF doch auch einfach erfragen:

    AutoIt
    Local $idDummy = GUICtrlCreateLabel('',0, 0, 1, 1) ; dummy control creation to get the current gui handle
Local $hGui = _WinAPI_GetParent(GUICtrlGetHandle($idDummy))
GUICtrlDelete($idDummy)

    Das sind 3 Zeilen mehr Code, die aber einen Parameter überflüssig machen. Das sollte es doch wert sein. ;)

    Das echte Dummy-Ctrl (GUICtrlCreateDummy) kann dafür nicht verwendet werden, da es ein Fake-Ctrl ist, das kein Handle besitzt. War mir nicht bewusst, wurde aber beim Testen klar.

    Falls also die Übergabe des Parameters einen tieferen Sinn haben sollte, erschließt sich dieser mir nicht. Vielleicht haben alle Autoren nach den 3 Lebensleitlinien gehandelt:

    • Das haben wir schon immer so gemacht!
    • Das haben wir noch nie so gemacht!
    • Da könnte ja jeder kommen!

    :rofl: