Beiträge von BugFix

    Das da wäre die beste Lösung, da Windows deinem Skript bescheid gibt, wenn sich in einem bestimmten Pfad was tun sollte,

    Zitat von _WinAPI_ShellChangeNotifyRegister

    Registers a window to receive notifications from the file system or Shell

    Kann man dann aber nur anwenden, wenn man eine Anwendung mit GUI laufen hat, was für Überwachungsskripte eher nicht der Fall ist. Ich habe bei mir ein Skript laufen, das alle 5 Sekunden in einem Ordner schaut, ob eine neue PDF abgelegt wurde. Diese wird dann nach bestimmten Kriterien umbenannt und an eine andere Anwendung weitergereicht. Dafür existiert selbstredend keine grafische Oberfläche.

    Ich vermute mal, bei HansJ54 sieht das ähnlich aus.

    Ach das ist so etwas wie ein If ... then ... elseif ... elseif?

    Das ist ein Ternärer Operator, hier mehrfach verschachtelt. Wirkt wie If-Then-Else, wobei Else immer belegt sein muss. Wenn man es untereinander schreibt, wird es deutlich:

    AutoIt
    $sTCPErrorText = _ ; Zuweisung
    (@error = -2) ? 'not connected' : _ ; wie: If-Then
    (@error = 1) ? 'IPAddr is incorrect' : _ ; wie: ElseIf-Then
    (@error = 2) ? 'Port is incorrect' : _ ; wie: ElseIf-Then
    (@error = 10060) ? 'Connection timed out' : _ ; wie: ElseIf-Then
    'Unknown error' ; wie: Else

    wie gut sieht es mit der geplanten Nutzung von Variablendeklarationen in Include Dateien aus?

    Kennst du vielleicht: Bei der Entwicklung des Skriptes fällt dir auf, dass sich noch ein ständig wachsender Haufen an Folgemaßnahmen erforderlich macht und dann schiebst du das erst mal vor dir her. :whistling: Ein wesentlicher Punkt (der mich auch bei meinem ManageIncludes gebremst hat) ist eine Routine zum rekursiven Auslesen/Vergleichen der Includes. Da habe ich schon etliche Ansätze probiert aber noch nichts (geschwindigkeitsmäßig) zufriedenstellendes gefunden. Dadurch dass viele Includes Querverweise auf andere Includes haben, landet man da schnell in einem InfinityLoop. <X

    Ich werde vermutlich das Parsen der Includes in ein externes (Nicht-AutoIt) Programm auslagern, das mit der notwendigen Geschwindigkeit arbeitet.

    Bei dem Projekt sind die Variablen nicht in der Hauptroutine deklariert, sondern die Dekalaration erfolgt über eine include Datei die die Variablendeklaration enthält. Um es noch komplizierter zu machen, gibt es für die Internationalisierung der GUI auch Include-dateien in zweiter Schachtelungsebene

    He, da ticken wir ähnlich. ;)

    In meinen (größeren) Projekten baue ich das so auf:

    - Mainskript (meist nur ein paar Zeilen: Includes, Initialisierungsaufrufe(Variablen, GUI), Mainloop)

    - getrennte Includes: Variablendeklaration, Variableninitialisierung, GUI-Erstellung, GUI-Funktionen, Programmfunktionen

    Aber ich halte das alles in einer Ebene.


    Bei derartigen Konstrukten ist das Problem, dass ein Include auf Variablen zugreift, welche in einem anderen Include deklariert sind, aber dieses Include noch nicht geparst wurde.

    Hier die richtigen Abhängigkeiten zu finden ist nicht ohne. Eigentlich müsste man dasselbe tun, wie der Interpreter: Alle Includes in einen gemeinsamen Kontext zusammenführen und dann parsen.

    Aber, wie schon oben beschrieben, wird eine Lösung für ManageIncludes auch hier ein bessere Umsetzung ermöglichen.

    wohin muss die GetUnusedVars.au3 kopiert werden

    $(SciteDefaultHome) ist das Installationsverzeichnis von SciTE. Das würde ich nicht zum Speichern eigener Anwendungen empfehlen. Verwende besser einen Ordner im Bereich USER, indem du Skripte (au3 und lua) für SciTE ablegst. Z.B. C:\Users\USER\MySciTE.

    Am Besten speicherst du diesen Pfad in der SciTEUser.properties (SciTE-Optionen-Benutzereinstellungen) als:

    User.Scripts.Path=C:\Users\USER\MySciTE

    Dann kannst du später in den SciTE.properties auf den Pfad immer zugreifen in der Form $(User.Scripts.Path).


    In deinem Fall also entweder:

    command.39.*.au3="$(autoit3dir)\autoit3.exe" "C:\Users\USER\MySciTE\GetUnusedVars.au3" "$(FilePath)" "1" "0"

    oder:

    command.39.*.au3="$(autoit3dir)\autoit3.exe" "$(User.Scripts.Path)\GetUnusedVars.au3" "$(FilePath)" "1" "0"

    Vorschlag für folgende Funktion:

    Ich habe mich jetzt mal etwas intensiver in das Thema eingelesen. Das Thema ist schon sehr vielfältig. Ich habe jetzt mal ein einfach zu handhabendes Szenario als Bsp. erstellt.

    Grundsätzlich gibt es ja 2 Möglichkeiten:

    a) Ich lasse das Programm/die Funktion in einen Fehler laufen und fange diesen dann ab

    b) Ich prüfe vor Ausführung ob z.B. Parameter fehlerhaft sind und generiere sofort selbst einen Fehler, der dann im Errorhandling weiter bearbeitet wird.


    Hier soll z.B. eine Datei eingelesen werden. Ich prüfe jetzt vorher, ob sie überhaupt existiert und generiere einen Fehler, falls nicht. Wenn Prozeduren Fehler generieren, ist die Art des Fehlers in den entsprechenden Modulen vermerkt (IOError, wImageError, ..). Fehler enden immer auf ..Error.

    Meine Dateiprüfung liefert aber keinen Fehler, sondern true/false. Somit ist es erforderlich einen eigenen Fehlertyp zu erstellen, dem ich dann auch einen entsprechenden Text beim Setzen mitgebe.

    Falls z.B. ein Dateihandle existiert, weil eine Datei zum Schreiben geöffnet wurde und dort ein Fehler auftrat, muss dem "except:" ein "finally:" folgen mit (in diesem Fall) close(f). Wichtig!: Der finally-Zweig wird IMMER ausgeführt (unabhängig ob Fehler oder nicht), also muss diese Aktion auch ausführbar sein und nicht selbst in einen Fehler laufen.


    Doku: Raise & Try


    P.S.

    Falls ihr noch weitere Bsp. zum Errorhandling habt, bitte hier posten. Das Thema ist so komplex, da ist eine Sammlung sicher hilfreich.

    Jetzt wäre es für mich überaus interessant zu wissen, wie ich Fehler abfangen und mit echo ausgeben kann, wenn das Verzeichnis oder eines der *.bmp nicht gefunden wird.

    In einem fertigen Programm mit Verweisen auf lokale Dateien kann es natürlich zu Fehlern kommen, wenn diese fehlen.

    Ich würde das Laden der Ressourcen somit als eigenständigen Part vor dem Hauptprogramm ausführen.

    Im folgenden Bsp. siehst du die Fehlerbehandlung. Im Falle eines Fehlers (hier wImageError) wird das Programm verlassen. Fehlermeldung in der Konsole: "Image Creation Failed".

    Hier Werden die Status-Images bei Expanded/Collapsed jeweils getauscht. Die Images habe ich hier gepostet.

    aber warum macht es einen Unterschied, ob da "UBound($aArray1Dim,$UBOUND_ROWS)-1" oder "0" steht?

    Ubound liefert die Anzahl der Elemente. Die Adressierung (Index) beginnt aber bei 0! Somit ist der letzte Index 1 kleiner als die Anzahl der Elemente (Ubound) - ergo: Ubound(..) -1

    ich brauche die erste Zeile, nicht die erste Spalte.

    Soll dann jeder Spaltenwert aus dieser "Zeile" als Einzelwert in das Array1D eingefügt werden?

    Wie kann ich leere Einträge ( = " " oder = "" ) in der ersten Zeile von $Array2Dim rausfiltern, so dass $aArray1Dim nur nicht-leere Einträge enthält und auch Ubound entsprechend kleiner ist?

    Beim Iterieren über die Einträge abfragen und ggf. verwerfen. Aber bevor du da ran gehst, lies bitte mein Array-Tut (Signatur). Dann sollte es für dich einfacher werden.

    Ich habe mir Symbole für Imagelisten erstellt: Unchecked | Checked | Plus | Minus | Dots | Pfeil-Auf | Pfeil-Ab | Pfeil-Rechts | Pfeil-Links

    Alles in den Farben: weiß | rot | grün | blau | gelb

    Jeweils für Status: Enabled | Disabled


    Vielleicht könnt ihr das mal gebrauchen.


    Das sind sie:

    Aber kannst Du mal diese Zeile genauer erklären (den roten Teil): snames.add(file.path.splitPath().tail.split('.')[0])

    Ich weiß, was da passiert, aber nicht wie.

    Ich habe das mal auf die einzelnen Schritte aufgedröselt:

    In der wNim Demo war kein Bsp, für das Treeview. Hier habe ich mal eines erstellt. Ich generiere Item-Namen und Bilder aus dem angehängten PNG-Ordner. Einfach im Pfad der *.nim speichern.

    Und so sieht das aus:

    Dateien

    • png.zip

      (2,39 MB, 19 Mal heruntergeladen, zuletzt: )