Beiträge von Slevin

  • Directory TreeView mit Checkboxen, gibt's da vllt was fertiges?

    Nachdem ich einen Beitrag von Scritch gelesen hatte und mir Robocopy wieder in Erinnerung kam, hab ich mir gedacht, meine Backup-Routinen neu zu überarbeiten. Bisher hab ich da alles mit VBS zusammengescriptet, aber ich muss gestehen, mir gefällt AutoIt mehr und mehr :)

    Das, was ich mir gerne vorstellen möchte, mag from the scratch ein wenig zuviel Arbeit für meine bescheidene Zeit sein, aber vielleicht gibt es ja bereits ne fertige UDF dafür:

    Es wäre perfekt, wenn man in einer TreeView Ansicht des Directorys die gewünschten Folder mittels Checkbox auswählen könnte, und wenn man in Subfoldern manche wieder deaktiviert, dann gibts halt die bekannte graue Checkbox ohne Haken drin.

    Für den Ansatz hab ich zumindest mal das hier gefunden:

    https://www.autoitscript.com/forum/topic/17…w-and-listview/

    https://www.autoitscript.com/forum/topic/12…-in-a-treeview/ (erstes Beispiel wählen, oder beim zweiten die UDF "Func _WinAPI_LockWindowUpdate($hWnd)" auskommentieren)

    Wenn jemand weitere scriplets, snippets oder was brauchbares kennt, würd ich mich sehr freuen.

    Cheers

  • FileCopy kopiert Dateien aus Unterordnern mit

    Micrsosoft stellt, was Kopieren angeht, mit Robocopy ein wirklich klasses Werkzeug zur Verfügung. Wenn man also nicht nur mal schnell eine Datei von A nach B schieben möchte und ein halbwegs sicheres Kopieren gewährleisten will, dann würde ich persönlich zu diesem kleinen Helfer raten. Backups lassen sich damit wunderbar einrichten und Mirroring ist ohne lustige Zusatzsoftware möglich.

    http://www.wintotal.de/robocopy-der-kopier-gigant/

  • Verständnisfrage zu "Local vs Global" in Bezug auf Geschwindigkeit und Ressourcenbelegung

    Ja leider, ich muss mich da einfach noch mehr in die Materie einlesen, von daher bin auch dankbar für jeden Hinweis und all die Hilfe, die ich hier erhalte.

    Ich bastel für gewöhnlich einfach so vor mich hin, meist Sachen in VBS. Aber memory-management hatte ich nie nötig zu beachten, da fehlts mir also einfach an Wissen.

    Aber du hast recht, ich werde das Script in Zukunft sicher auch für andere Zwecke umbauen, und dann wäre sowas nicht gerade smooth...

  • Verständnisfrage zu "Local vs Global" in Bezug auf Geschwindigkeit und Ressourcenbelegung

    Bitnugger, das ist wirklich gut, danke :)

    Drei Fragen hätte ich da noch zu deiner Version:

    1. Hat das separate Deklarieren und Schließen von Global $g_hDll = DllOpen("shell32.dll") einen Vorteil?

    2. Wieso hast du beim Setzen des Tray-Icons ein Error-Handling angefügt, würden eventuelle Fehlermöglichkeiten nicht schon vorab ausgeschlossen werden?

    3. Kann man einem Errorhandling auch eine UDF zuweisen, in etwa so: If @error Then _exitFunction() ConsoleWrite("@@ Debug line" & ...

  • Verständnisfrage zu "Local vs Global" in Bezug auf Geschwindigkeit und Ressourcenbelegung

    Zitat von Oscar

    Du machst einen gravierenden Fehler!

    Mit _GDIPlus_BitmapCreateFromMemory erstellst Du bei jedem Aufruf eine neue Bitmap. Diese werden aber beim verlassen der Funktion nicht wieder freigegeben. Das führt zu einem Speicherleck.

    Besser einmal (global) die Icons erstellen und dann diese nutzen und bei Programmende wieder freigeben.

    Das behebt nicht nur das Speicherleck, sondern ist auch schneller.

    Also entweder wie autoiter meinte, die _setTrayIcon() UDF so gestalten:

    AutoIt
    Func _setTrayIcon($icon)
    $hBmp = _GDIPlus_BitmapCreateFromMemory(_WinAPI_Base64Decode(_fetchIcon($icon)))    ;load ico and convert it to a GDI+ bitmap
    $hIcon = _GDIPlus_HICONCreateFromBitmap($hBmp)                    ;convert bitmap to HIcon
    _WinAPI_TraySetHIcon($hIcon)
    _GDIPlus_BitmapDispose($hBmp)
    _WinAPI_DestroyIcon($hIcon)
EndFunc

    Oder aber jedes Icon global fertig deklarieren, das würde dann jeweils in etwa so aussehen:

    AutoIt
    Local $iconBaselock = 'AAABAAEAEBAAAAEACABoBQAAFgAAACgAAAAQAAAAIAAAAAEACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjI7EAIiKwACIirwAhIa4AICCtAB8frAAeHqoAHR2pABwcpwAbG6UAGRmkABgYogAXF6AAFhaeABQUnAATE5oAEhKZABAQlwAPD5UA8fHxAA0NkwAMDJEACwuPAAoKjQAICIwABweKAAYGiAAFBYcABASFAAMDhAACAoMAAQGCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADxAREhQVFhcYGRobHB0eHw4PEBESFBUWFxgZGhscHR4NDg8QERIUFRYXGBkaGxwdDA0ODxAREhQVFhcYGRobHAsMDQ4PEBETExUWFxgZGhsKCwwNDg8QExMUFRYXGBkaCQoLDA0ODxMTEhQVFhcYGQgJCgsMDQ4TExESFBUWFxgHCAkKCwwNExMQERIUFRYXBgcICQoLDBMTDxAREhQVFgUGBwgJCgsTEw4PEBESFBUEBQYHCAkKExMNDg8QERIUAwQFBgcICQoLDA0ODxAREgIDBAUGBwgJCgsMDQ4PEBEBAgMEBQYHCAkKCwwNDg8QAAECAwQFBgcICQoLDA0ODwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA='

Global $iconBase = ObjCreate("Scripting.Dictionary")
$iconBase("lock") = GDIPlus_HICONCreateFromBitmap(_GDIPlus_BitmapCreateFromMemory(_WinAPI_Base64Decode($iconBaselock)))

Func _setTrayIcon($icon)
    _WinAPI_TraySetHIcon($icon)
EndFunc

_setTrayIcon("lock")

    Wenn ich das jetzt richtig verstanden habe, dann wird bei der ersten Variante jedes Mal das Icon aufs neue kreiert, aber der für das Erstellen des Icons benötigte Bitmap-Speicher wieder freigegeben.

    Bei der zweiten Variante werden alle Icons fertig kreiert und bleiben im Speicher, sind daher schneller ansprechbar, und es gibt auch kein Speicherleck - was insgesamt wahrscheinlich die intelligentere Variante ist, sofern sich das ganze in Grenzen hält (wie gesagt, so um die 20 Icons im aktuellen Fall)

    Das mit dem Speicherleck wäre natürlich gar nicht gut gewesen - DANKE für die Warnung

  • Verständnisfrage zu "Local vs Global" in Bezug auf Geschwindigkeit und Ressourcenbelegung

    Aloha und nen schönen Feiertag,

    ich hab da mal ne allgemeine Frage. Wie ihr im beigefügten Script sehen könnt, belegen die embedded Icons, die als String in einem Dictionary abgelegt sind, ganz schön was an Platz.

    In meinem Beispiel würde bei jeder Tray-Icon-Änderung die _fetchIcon() UDF aufgerufen werden, in welcher sämtliche Icons Local deklariert sind - für das Beispiel hier nur 2 Icons, im eigentlichen Scipt sind das dann aber bis zu 20 oder mehr. Diese liefert dann den gewünschten String zurück, der im Anschluss dekodiert und als Icon gesetzt werden kann.

    Das bedeutet natürlich, dass jedes Mal alle Icons frisch in den Speicher geladen werden müssen, was natürlich auch Zeit in Anspruch nimmt.

    Daher meine Frage: sollte man die Icons lieber Global speichern und zu Beginn des Skripts einlesen? Würde das einen Geschwindigkeitsvorteil bringen? Vor allem, wenn die String-Variablen, wie in diesem Beispiel, eine ganz schöne Länge haben.

  • Icons aus der resource-table ins dictionary laden - geht das?

    Zitat von NO1 :-)

    Dann legst du bis zur Auslieferung die Icons in nen extra Ordner und danach kannst du es ja immer noch umändern. Aber mein Tipp: Verwende eine DLL. Da kannst du alle Icons reinspeichern und ganz leicht mit TraySetIcon aufrufen. Dann hast du nur eine Datei für alle Icons.

    Ob die Icons in einer separaten DLL oder in der kompilierten EXE selbst liegen ist doch egal, oder übersehe ich da was?

    Es geht mir um das Verständnis, ob es möglich ist, eine Variable zu deklarieren, mit der ich ein Icon aus einer Datei für TrySetIcon ansteuern kann. Ich weiß nicht, wie ich es besser ausdrücken soll. Das Icon befindet sich in der EXE, und die Variable soll die EXE und die Position an TraySetIcon übergeben.

    autoiter Der "File to Base64 String Code Generator v1.20 Build 2015-01-20" klingt nicht nur für diesen Zweck sehr interessant. Hast du das Skript ausprobiert? Bei mir gibt es Deklarationsfehler von Const-Variablen, mal schaun, woran das liegen könnte - vielleicht, weil manche includes von von 2015 andere Variablen haben.

  • Icons aus der resource-table ins dictionary laden - geht das?

    Die Icons liegen in einem Unterordner und werden beim Compilieren ins Script miteingebunden. FileInstall will ich nicht vornehmen, das mache ich maximal nur für die Settings.ini.

    Das Script soll zuhasue unkompiliert laufen, da hab ich für mich auch kein Problem damit, dass die Icons in einem separaten Ordner liegen. Gleichzeitig aber soll das Skript als selbständiges Tool kompiliert ohne Installationsroutine (auch ohne FileInstall) weitergegeben werden können.

    Ich mag's selbst auch überhaupt nicht, wenn kleine Helferprogramme unzählige Dateien und Ordner brauchen - va, wenn das nicht zwingend sein muss. Klein und fein, so sollt es sein :)

    Und da dachte ich halt, vielleicht gibt es eine Möglichkeit, die Dictionary-Variable je nach Bedarf zu befüllen, entweder mit einer Adressierung zum physisch vorhandenen Icon im Unterordner oder aber zu einem Icon in der Resourcen-Tabelle. Und in weiterer Folge dann mit Hilfe dieser Dictionary-Variablen TraySetIcon anzuweisen seine Arbeit zu verrichten.

  • Icons aus der resource-table ins dictionary laden - geht das?

    @autoiter, ja, das ist ein Ansatz der zumindest funktioniert.

    Allerdings hoffte ich auf eine Möglichkeit, die es sowohl erlaubt, das Skript unkompiliert als auch kompiliert laufen zu lassen.

    Über das Skript verteilt wird das TrayIcon unzählige male geändert. Es ist im Grunde das wichtigste Kommunikationsmittel. Deine Variante würde jetzt leider nur compiled funktionieren.

    Ich will mal zeigen, wie das in etwa aussieht:

    Natürlich funktioniert der Abschnitt @Compiled so nicht. Ich wüsste sonst noch eine Variante, bei der eine eigene Funktion das Setzen der Icons übernimmt. Dann wäre zumindest an allen Stellen im Skript, wo das Icon getauscht wird, ein einheitlich verständlicher Code vorhanden.

    Ich hoffte halt auf eine etwas elegantere Lösung :S

  • Icons aus der resource-table ins dictionary laden - geht das?

    Ich würde gerne Icons, die sich im resource-table des kompilierten Scripts besfinden, in ein dictionary laden, um sie anschliessend mit Namen ansprechen zu können. Geht sowas überhaupt?

    Der nachfolgende Versuch haut jedenfalls schon mal nicht hin^^

    Vielen Dank

  • Verständnisfrage zu "INI-Datei Keys, die mit vera beginnen"

    Vielen Dank @Musashi für die Hintergrundinformationen.

    Es scheint wohl daran gelegen zu haben, dass die INI-Datei irgendwie *zwitterhaft* war. Ich hatte die Pfadangaben aus DOpus (Explorer-Ersatz) kopiert. Als es dann Probleme gab, hatte ich die INI in UTF-8 konvertiert. Und ab da war dann nix mehr nachvollziehbar, bis auf dass es mit "vera" besonders lustig wurde. Da es allerdings, aus welchem Grund auch immer, nicht ständig Probleme gab, es also hie und da auch mal funktionierte, kam ich erstmal natürlich nicht auf die Idee, dass es an der Codierung liegen könnte.

    Alles klar, und danke für die Infos.

  • Verständnisfrage zu "INI-Datei Keys, die mit vera beginnen"

    Ich bin da auf etwas zumindest für mich sehr skurriles gestoßen.

    Ich möchte in der INI-Datei unter anderem Pfade zu einem Programm deklarieren. Komischerweise bekomme ich return-Fehler, wenn die Keys in der INI-Datei mit "Vera" beginnen.

    Code
    ;; INI Datei

[VeraCrypt]
VeraCryptPath = C:\Programme (portable)\+ ..... System & Utilities\+ ..... Dateien & Ordner\VeraCrypt\VeraCrypt-x64.exe
    AutoIt
    $VeraCryptPath = IniRead($FileSettings, "VeraCrypt", "VeraCryptPath", "0")

    Ist "Vera" irgendwie geschützt? Ich mein, da muss man auch erst mal drauf kommen - hab ne gute Ewigkeit lang rumgespielt um einen Fehler zu finden, den es in meinem Verständniss so gar nicht gibt :party1:

  • Map Deklaration throws error

    Also Map als Variable gibt es demnach gar nicht? Dann sollte man das vllt auch aus der Referenz rausnehmen^^

    Bitnugger:

    Wie alpimes richtig erkannt hat, geht es ja darum die Icons mit einer logischen Bezeichnung zu adressieren und nicht mit einem Array rumzuspielen.

    Die fehlenden $ sind der Schlampigkeit geschuldet, hier auf die Schnelle den Sinn meines Anliegens darzustellen - sorry dafür

    alpines:

    Aktuell verwende ich Version 3.3.14.5

    Danke für die Alternativen, große Hilfe. Mal schauen, welche der beiden Varianten mir sympathischer rüberkommt :)