Beiträge von Kanashius

    Es kommt zwar drauf an, wie viele Geräte du generell verwerwaltest,... Aber ich würde in Erwägung ziehen, die Infos nach Gerät zu speichern und dann ggf. alle durchiterieren, um die Geräte zu finden, die die Fehlermeldung haben.

    Selbst wenn du 10000 Geräte hast dürfte das durchlaufen nicht lange dauern.

    Wenn du aber beim Gerät hinzufügen/ändern, alle Stellen zum hinzufügen/entfernen der Infos suchen musst, dürfte das länger dauern. Insbesondere, wenn sich bei nem Gerät durch nen update,... die Fehlermeldung ändert, weil du dann ja nicht nur die aktuellen Infos brauchst, sondern auch die vorherigen, um zu sehen, bei welcher Fehlermeldung du das Gerät rausnehmen musst,...


    Also, wenn du diese JSON-Daten nicht aus anderen generierst, sondern manuell pflegen willst, würde ich überlegen, die Struktur anders zu gestalten.

    Besser den PC 1-2 Sekunden alle Objekte durchsuchen lassen, als selber Stunden zu verbringen, Daten anzupassen :D

    Wenn Geschwindigkeit trotzdem zu langsam ist, würd ich immernoch die Geräte als JSON ablegen und dann das nach Fehlercode sortierte JSON daraus generieren.


    Aber ob das in deiner Anwendung notwendig/sinnvoll ist wirst du vmtl. besser wissen :)

    Ich vermute, dass die Simulation von Windows her deaktiviert ist (also vmtl. auch _winapi_keybd_event).

    Was aber funktionieren sollte ist, einen Treiber zu installieren, der angibt ein Eingabegerät zu sein und darüber die Tastatur zu bedienen. Also nen virtual keyboard driver.

    Auf die schnelle hab ich diesen finden können. Habs aber nicht getestet.

    GitHub - hedgar2017/loki-hidriver: Virtual mouse and keyboard driver for Windows 7 and higher
    Virtual mouse and keyboard driver for Windows 7 and higher - GitHub - hedgar2017/loki-hidriver: Virtual mouse and keyboard driver for Windows 7 and higher
    github.com


    (Du musst zum installieren vmtl. kurzzeitig unsignierte Treiber erlauben. Also den Code vom link am besten selber kompilieren, um sicher zu sein :).)

    Naja... genau was da steht: Die Variable wurde vorher als Konstante deklariert.

    Du kannst die Variable also nicht später neu zuweisen. Wenn du den Block mehrmals in deinem Script hast, wird es sich beschweren.


    Am besten postest du das ganze Script. Ich vermute stark, dass du Arrays verwenden solltest (anstatt den Code mehrmals zu kopieren,...).


    Ansonsten: Einfach das const überall weglassen, wo du die Variable deklarierst/definierst.

    Ich bin mir grad nicht ganz sicher, wie windows es macht, aber macht es nicht sinn, einfach immer das aktuelle maximum zu nehmen?

    Wenn nen höherer Wert kommt wird die Grafik größer und es gibt nen neues maximum. Ist ja auch relativ sinnvoll, weil Festplatten normal mit der Zeit langsamer speichern, je mehr Daten ankommen (sobald caches,... voll sind).

    Daher sind die größten Werte eher am Anfang.

    Steam arbeitet bei den Downloads aber auch so, glaub ich.

    Ich konnte mir die ganzen sich wiederholenden Zeilen nicht mit anschauen, also hab ich es mal passend mit nem Array erstellt.

    Arrays werden immer genutzt, wenn man das gleiche mehrmals machen würde und sich nur wenig ändert und vermeiden eine Menge Code, der eigentlich nur Copy-Pasted wird.

    Wenn du links hinzufügen, Icons (und Hover-Icons) ändern willst und die Aktion beim klicken ändern willst (z.B. Excel statt firefox) musst du mit dieser Variante nur das Array verändern und ggf. eine neue Funktion unten hinzufügen.

    Auf diese Weise ist alles dynamisch generiert und die Höhe des Fensters passt sich z.B. an die Anzahl der Links automatisch an.


    Bei fragen meld dich gern wieder :)


    MfG Kanashius.

    Du kannst mit ShellExecute(@Scriptname) dein Programm neustarten und dann das aktuelle mit Exit beenden. (Funktioniert ggf. nur mit der .exe Anwendung, kommt drauf an, was Standartmäßig .au3 bei dir macht).

    Wozu soll das gut sein?

    Ich vermute mal, dass es gert_nrw_71 um das Problem im andern Thread geht, dass der Scanner nach einiger Zeit nicht mehr funktioniert und du dann das Script neustarten willst.

    Ich würde empfehlen, stattdessen das eigentliche Problem zu beheben, sodass nicht neugestartet werden muss. Gerade wenn man nicht genau weiß, was das Problem ist, sollte man mit Debugging (z.b. ConsoleWrite) herausfinden, wo das Problem liegt und es beheben.

    Solange man nicht weiß, wo genau das Problem ist, kann es passieren, dass der neustart z.B. nicht rechtzeitig ist, weil es auf einem anderen System viel schneller zu Problemen kommt,...

    Und dann hat man ggf. komische Nebeneffekte und weiß nicht, wo sie herkommen.

    Erstmal: Mehrere/Viele GUIs sind kein Grund, mehrere Scripte zu schreiben. Das kann alles in ein Script, bzw. auch eine Datei.

    Der einzige Grund, warum man in AutoIt mehrere Anwendungen (.exe - Dateien) benötigt, bzw. eine Anwendung mehrmals ausführen muss ist multiprocessing. Wenn man mehrere Dinge gleichzeitig verarbeiten will, wobei Geschwindigkeit wichtig ist, sodass man mehrere Prozessorkerne nutzen muss.

    Deshalb vermute ich gerade, dass du einen Design/Denk Fehler hast, weshalb du die ganzen Scripte eig. gar nicht benötigst. Macht also ggf. Sinn, wenn du uns deinen Code zeigst, bzw. deinen genauen Grund für mehrere Scripte.


    Ansonsten zu deiner eigentlichen Frage: Wenn du eine mit AutoIt compilierte .exe hast kann die meines Wissens nach andere .au3 Dateien ausführen. Hab ich aber selbst noch nie gebraucht/gemacht, solltest du aber finden, wenn du danach suchst.

    Alles was du hier mit verschlüsseln,... machst wird niemanden, der wirklich will, davon abhalten, dass er an den Code rankommt. AutoIt ist eine Scriptsprache, es ist also ohne Probleme möglich an den Code (auch von der .exe) zu kommen. Du betreibst also nur Obfuskation.

    Probier dasselbe, was ich bei dem Beep vorgeschlagen hab auch fürs FileWrite. Also $sBuffer global machen und beim beep (in der hauptschleife) auch ins log schreiben.

    Wenn du lang dauernde Codeteile (Abhängig von der Festplatte kann schreiben nen moment dauern, wobei es eig. von windows gebuffert werden sollte... ) aus den Funktionen rausnimmst, die direkt aus der _KeyProc aufgerufen werden und stattdessen nur eine Variable setzt und dann später in der Hauptschleife auf die geänderte Variable reagierst, blockierst du die _KeyProc Funktion nicht.


    Ich vermute, dass das Betriebssystem bei FileClose die Daten tatsächlich auf die Festplatte schreibt und das Script darauf wartet. Es könnte also auch helfen, wenn du das FileOpen und FileClose woanders machst. Wird aber schwer, weil du ja den Code als Dateinamen nutzt...

    Hi :)


    Erstmal zum Stil:

    Konsistenz bei Variablen/Funktionen Benennung: $hWH_Timer / $__chBTN_TimerStart / $g_iSecs / _Timer_WIN() / __TimerStart() / _Timer()

    Du solltest einen Stil wählen und dann dabei bleiben.

    In AutoIt wird bei Variablen und Funktionen normalerweise mit camelcase gearbeitet. Also am Anfang klein und dann jedes neue Wort mit nem Großbuchstaben.

    z.B. $gTimerMainGui, $iTimerTimeLabel oder timerStart(), timerStop()

    Bei Funktionen werden interne AutoIt-Funktionen am Anfang groß geschrieben z.B. GuiGetMsg(), GuiCtrlSetData(), ...

    UDFs die von mit AutoIt ausgeliefert werden (in der Hilfe zu finden sind) fangen auch mit einem _ an und haben dann den UDF Namen, gefolgt von der Funktion.

    z.B.: _GDIPlus_PenSetColor, _GDIPlus_RectFCreate, ...

    UDFs, die nicht mit AutoIt selbst kommen fangen mit __ an und sonst wie eine normale UDF.

    z.B. für meine Wallpaper UDF: __Wallpaper_InitDefaultTray(), __Wallpaper_Start, ...

    Deshalb schreibt man eigene Funktionen am Anfang klein oder (wie ich meistens) mit einem _ am Anfang, um nicht ausversehen Funktionen gleich zu nennen und Konflikte zu vermeiden.

    Also in deinem Fall: _timerStart(), _timerStop(),...


    Für Variablen gelten die gleichn Regeln, nur dass man noch am Anfang das kürzel für den Dateityp hat. Also z.B. $hTimer, $iTimerLabel,...

    Bei UDFs dann dementsprechend $__Wallpaper_bRunning, $__Wallpaper_bClear, ...


    Ansonsten schaut das schon ganz gut aus (ich vermute mal die Formatierung wurde beim posten durcheinander geworfen).


    In deiner Haupt-Scheife solltest du ein Sleep einbauen, um Resourcen zu sparen. Der Nutzer merkt es nicht, ob 10ms vergehen, bis auf den Buttonklick reagiert wird. Dafür ist die CPU nicht permanent damit ausgelastet die Schleife zu durchlaufen.

    Code
    While Sleep(10) And Not $bEnd
        Switch GUIGetMsg()
            Case $iTimerExitButton
                _timerExit()
            Case $iTimerStartButton
                _timerStart()
            Case $iTimerPauseButton
                _timerPause()
        EndSwitch
    WEnd

    Wenn ich mehrere Controls (hier die buttons) habe, die die gleiche größe haben und sehr Strukturiert angeordnet sind nehm ich gerne nen Array (s. Beispiel), da ich jetzt ohne Probleme die größe des Fensters erhöhen könnte und einen Button ins Array hinzufügen kann, ohne dann alle anderen Werte anpassen zu müssen. Ich hab allgemein die Controls so erstellt, dass du einfach $iTimerGuiWidth ändern kannst und alle Controls werden passend mit skaliert.


    Z.B. Local Static $iTimerCount = 0 ist nützlich, wenn man eine Variable nur in einer Funktion benutzt, die Funktion aber öfter verwendet wird. Sorgt für weniger globale Variablen.


    Ansonsten evtl. drauf achten, dass Deutsch/Englisch einheitlich bleibt. (z.B. $Ende, wo auch der Typ (boolean) fehlte).


    So etwa hätte ich das umgesetzt:

    Ich hab statt dem Adlibregister einfach einen Call in der Hauptschleife genutzt.

    Kann ggf. nicht so gut funktionieren, wenn in deinem größeren Programm dann mehrere Schleifen sind.


    Hoffe, das hilft dir etwas weiter :).


    MfG Kanashius.

    Dein Rot (ich nehme mal RGB an) FF0000 würde somit Türkis 00FFFF werden (ob autoit das so abbilden kann und macht in diesem Fall kann ich nicht sagen)

    Da NOT in Autoit ein boolean erwartet und das dann invertiert, wird die Zahl erst zu boolean konvertiert. Da alles außer 0 True ist, wird 0xFF0000 also zu True und dann negiert => Not 0xFF0000 ist also False.

    warum gibt es kein XOR

    XOR ist ein Fall, der sehr selten benötigt wird. Deshalb lohnt es sich nicht, dafür einen eigenen Operator einzuführen. Insbesondere, weil der nicht dem normalen Schema entsprechen würde, dass bei der ersten fehlgeschlagenen/zutreffenden Bedingung beendet werden kann.

    => Kurzschlussauswertung funktioniert nicht: Ist bei einer And Verknüpfung der erste boolean falsch muss der zweite nicht mehr überprüft werden. Selbiges bei Or, wenn der erste bool wahr ist.

    Außerdem kann man XOR einfach mit Not a <> Not b darstellen.

    Google => man curl: https://curl.se/docs/manpage.html#-d

    -d ist also der data block in ascii form => String

    Der Inhalt sieht auch nach JSON aus, das passt also.

    _WinHttpSimpleRequest($hConnect, $sType = Default, $sPath = Default, $sReferrer = Default, $sData = Default, $sHeader = Default, $fGetHeaders = Default, $iMode = Default) hat ein $sData feld, dass dafür da sein dürfte.

    Also würde ich das hier versuchen:

    AutoIt
    $sData = '[{"Feldname1": "Wert1", "Feldname2": "Wert2"}]'
    $sHeader = 'header-1: The Header '&@crlf&"header-2: lines"
    $sPath = "www.google.com/search"
    $hHttp = _WinHttpOpen()
    $hConn = _WinHttpConnect($hHttp, "http...") ; http... bis zum ersten / (exclusive) => die domain => (www.google.com)
    $sResult = _WinHttpSimpleRequest($hConn, "POST", "/rest of the path", Default, $sData, $sHeader, Default, Default) ; Last one may be 0 -> Ascii; 1->UTF-8, 2->Binary
    ; /rest of the path after the first / (inclusive) => (/search)
    _WinHttpCloseHandle($hConn)
    _WinHttpCloseHandle($hHttp)

    Ich habs nicht getestet und mir nur die UDF angesehen, aber es sollte so funktionieren.

    Hi, ich hatte mir deinen Code gestern angesehen und fand es unglücklich, dass du jede Minute ein neues Bild erstellst, es als Datei speicherst und dann als Hintergrund setzt.

    Das ist eine echt gute Methode, wie du sehr schnell deine Festplatte kaputt schreibst. Bei mir ist das Hintergrundbild (2x4K und 2xFHD Bildschirm) ca. 11MB groß...

    Das wären ~15.840MB => ~16GB in 24 Stunden, die dort geschrieben werden...


    Deshalb hab ich mir gestern ein paar Stunden angeschaut, wie genau die Fenster vom Desktop funktionieren und hab eine UDF geschrieben, mit der man auf den Desktop zeichnen kann.

    Ich hab dein Script mal mit der UDF umgesetzt. Das würde dann so ausschauen:

    Ich hab noch die Sekunden hinzugefügt, weil warum nicht :D


    Edit: Link zur UDF: Wallpaper UDF

    Edit2: _getMaxRect() removed

    Hi, ich habe eine kleine Bibliothek geschrieben, mit der auf ein Fenster hinter den Desktop-Icons gezeichnet werden kann. Sie erlaubt das zeichnen auf das Wallpaper mit GDI+ ab Windows 8.

    Da GDI+ genutzt wird, ist es nicht ganz so schnell, aber ich komme in meinem Beispiel Script immernoch auf 60-120fps.


    Theoretisch kann man die Funktionen auch nutzen, um ein eigenes Child-Fenster mit Controls zu erzeugen (in __Wallpaper_Startup $hWorkerW ist das benötigte Fenster), falls das für jemanden interessant ist.


    Viel Spaß damit :) .


    Beispiel:

    Und ich selber versuche so wenig wie möglich Global zu setzen, alles was man nur Lokal braucht, gehört für mich nur in einen Lokalen Kontext.

    Da würde ich definitiv wiedersprechen. Konstanten gehören niemals lokal. Außerdem sollte GDIPlus beim Programmstart gestartet und beim beenden geschlossen werden, wenn die Funktionen öfter benutzt werden. Es erzeugt performance mäßig einfach viel zu viel overhead, ständig zu laden und wieder freizugeben.


    Ich würde immer die Performance als erstes sehen, weil das vom Nutzer am ehesten bemerkt wird. Dann den Speicherverbrauch. Ist heutzutage nicht mehr ein ganz so großes Problem, deshalb wirds nicht allzu schnell auffallen. Und später kommt irgendwann Stil, also wenn möglich lokal,... (Natürlich alles im Rahmen, wenn es nicht anders geht muss man kompromisse eingehen.) Wenn es zu viele Globale Variablen werden, sodass es unübersichtlich wird, muss man halt auf mehrere Scripte aufteilen.


    Lokal gehören nur alle temporären Variablen, die nur während eines Funktionsdurchlaufes verwendet werden. Bei denen macht es keinen Sinn, sie Global anzulegen.


    Hier wüde ich sagen hängt es davon ab, wie oft das Wallpaper geändert werden soll. Wenn es manuell hin und wieder gewechselt wird würde für mich der Speicher evtl. wichtiger sein, weils eh nur alle paar Tage aufgerufen wird => Performance ist weniger wichtig (sollte aber auch nicht wenige Sekunden überschreiten). => Lokal anlegen und wieder freigeben.


    Wenn es automatisch alle X Sekunden/Minuten wechselt sollte für Performance optimiert werden. => Global anlegen


    Wobei ich vmtl. hier einfach nur auf Performance gehen würde und eher Global allokieren würde, weil der Speicherverbrauch so gering ist, dass er nicht ins gewicht fällt. Bei GBs an RAM sind nen paar KB egal.

    Da du versuchst json zu verarbeiten, könnte es sinnvoll sein, wenn du dir die JSON-UDF mal anschaust:

    Wenn ich mir den Code bisher so ansehe, hast du glaub ich, noch nicht ganz verstanden, was Variablen sind.

    Variablen sind ausschließlich dazu da, Daten zu speichern. Sie verändern nichts. Zum Verändern sind Funktionen da.

    Wenn du also z.B. GUICtrlSetColor($acLabel, $col) aufrufst, wird mit den Werten gearbeitet, die zu dem Zeitpunkt in den Variablen stehen und übergeben werden. Zum Zeitpunkt des Funktionsaufrufs bezieht sich $acLabel auf das Control und $col enthält die Farbe.

    Wenn du aber z.B. $col = "0xFFFFFF" ausführst, wird nur ein anderer Wert in die Variable gespeichert. Dadurch verändert sich nichts. Erst wenn du die Funktion GuiCtrlSetColor erneut mit $col aufrufst, wird die Farbe verändert, da nun ein anderer Wert in $col steht.


    Variablen sind also reine Speicher für Daten/Informationen, die man dann an Funktionen übergibt, die damit weiterarbeiten.

    Das Ändern einer Variable löst aber keine andere Aktion aus, außer, dass in dem Datenfeld jetzt etwas anderes steht.

    Solange die Variable nicht woanders ausgelesen/verwendet wird, ändert sich auch nichts.