Beiträge von Xenon

    Habs jetzt nicht ausprobiert, vermute aber, dass das einer dieser Jahrmarktstricks ist.

    Ganz genau! :Glaskugel: Hier für alle Neugierigen mal meine Lösung:


    Hi,

    ich verstehe deine Interpretation und warum das aus deiner Sicht unlogisch erscheint. Allerdings haben reguläre Ausdrücke verschiedene Anwendungsfälle. Im Gegensatz zu deinem Beispiel möchte man häufig eben nicht nur prüfen, ob ein gesamter String einem Muster entspricht (Ja-Nein-Entscheidung), sondern aus einem String unbekannte Teile herausfiltern / suchen.


    Kurzes Beispiel:

    Aus "Wir treffen uns morgen um 13:35 Uhr am Bahnhof." soll die Uhrzeit herausgefiltert werden. Dann ergibt es natürlich Sinn, dass mein Pattern nur den wesentlichen Teil beinhalten muss, nämlich (ganz vereinfacht) "\d{2}:\d{2}". Alles andere würde hier zu Unleserlichkeit führen. Damit hast du genau dein gewünschtes Verhalten:

    Nach meinem Verständnis von RegEx sollte man explizit angeben, was man matcht und nicht, was man nicht matcht.

    Besonders bei den Flags 1-4 ergibt diese Substring-Suche deutlich mehr Sinn. Und wie du auch selbst bemerkt hast, ist deine gewünschte Funktionalität ebenfalls umsetzbar, man muss halt nur String-Anfang und -Ende explizit angeben:

    Immerhin geht "\A(a|b|c)\Z". Ist zwar hässlich und wird mich irgendwann zwingen \A und \Z nachzuschlagen, wenn ich den Code überarbeite, aber scheinbar muss das in Autoit dann so. Danke.

    Kleine Off-Topic-Anmerkung dazu: Dieses "hässliche" Verhalten ist nicht nur AutoIt-spezifisch, das hat sich unter anderem auch in PHP oder Linux bewährt.


    Viele Grüße

    Xenon

    Hallo,


    dein erwünschtes Vorgehen sollte mit folgenden AutoIt-Funktionen in wenigen Zeilen umzusetzen sein:


    1a) Datei installieren (in der AutoIt-EXE eingebunden)

    FileInstall


    1b) Alternativ nur die Datei kopieren, falls du das möchtest:

    FileCopy


    2) Shortcut erstellen:

    FileCreateShortcut


    Auf der jeweiligen Hilfeseite findest du neben der Erklärung unten auch immer ein Beispiel, wie der Befehl genutzt werden kann.


    Viele Grüße

    Xenon

    Hi hanady,


    So if I understand you correctly, you would like to install (any?) program silently in the background and have an AutoIt GUI showing the progress during installation?

    I don't want to be pessimistic but this seems pretty close to impossible. How is the AutoIt script supposed to figure out the current progress status? Only the installer script knows what it's doing internally. This approach might be possible for a specific installer - but only if the installer provides this information to the calling AutoIt script.


    Btw: Do you really need a progress bar? Usually, progress bars only provide a rough estimation anyway. (All of us encountered Windows updates getting stuck at 99%...)


    If you definitely need the progress bar, couldn't you just execute the GUI installer of the program and not implement this functionality yourself?


    This might be a better approach to your overall problem. Could you elaborate further on what you are trying to achieve?

    Eine dynamische Anpassung des Sicherheitskontexts (Admin/User) ist meines Wissens nach leider nicht möglich. Dies geht nur durch Starten eines neuen Prozesses, siehe dazu auch das Codebeispiel zu _Security__CreateProcessWithToken oder die folgende Diskussion: UAC Elevate and DeElevate Scripts.


    Dementsprechend sind mindestens zwei Prozesse nötig, daher ist die Vorgehensweise von Moombas sinnvoll. Ein ganz einfaches Beispiel sähe so aus:


    Der Nachteil dieser Methode ist, dass für jede Admin-Aktion die UAC-Abfrage erneut angezeigt wird, da ein neuer Prozess gestartet wird. Das kann ganz schön nervig werden.


    Je nach deinem konkreten Anwendungsfall kann es daher mehr Sinn ergeben, auf eines von meinen oben verlinkten Beispielen zurückzugreifen. Alternativ könnte man auch das Admin-Skript nur einmal starten und dann über Interprozesskommunikation die auszuführenden Aktionen übermitteln.

    Hallo HansJ54,


    folgendes Beispiel geht bei mir:

    ABER: Nur, wenn die Anwendung NICHT aus SciTE heraus ausgeführt wird (per F5). Das liegt sicher daran, dass SciTE diesen HotKey selbst für das Beenden des Skripts reserviert.

    alpines Das ist ein guter Hinweis!


    Natürlich könnte man dann stattdessen auch gleich eine eigene temporäre GUI nehmen, dann hat das ganze gar keine Seiteneffekte:


    Allerdings könnte man spätestens dann auch überlegen, ob man nicht in die ohnehin erstellte GUI einfach noch ein Inputfeld einfügt, und den Aufruf von InputBox komplett weglässt. ;)

    Hallo HansJ54,


    du hast recht: Die InputBox hat keinen Parameter, um sie immer im Vordergrund anzuzeigen.

    Wie man das ganze dennoch realisieren kann, ist hier ganz gut beschrieben: https://www.autoitscript.com/f…1-always-on-top-inputbox/

    (Übrigens erstes Google-Ergebnis zu "autoit inputbox foreground".)


    Wenn man einen der Vorschläge von guinness noch in eine hübsche Funktion auslagert, kann sowas dabei rauskommen:


    Die Verwendung der Funktion _InputBoxOnTop() sollte damit genau so sein wie bei der normalen InputBox. Das zeigen auch die ersten Zeilen im Codebeispiel.


    Viele Grüße

    Xenon

    Sehr interessante Sache...


    Bei mir sieht's ähnlich aus, allerdings ist die zweite Zeit im Verhältnis nochmal ein bisschen größer:


    > ------------------------------------------

    > >>>>> Check 1.1 - Calc() vor MsgBox <<<<<

    ! Elapsed time = : 672.835 ms

    > >>>>> Check 1.2 - Calc() nach MsgBox <<<<<

    ! Elapsed time = : 8955.305 ms

    > ------------------------------------------


    Wie autoiter schon meinte, tritt das Problem auch auf, wenn man anstatt der MsgBox z.B. Folgendes ausführt:


    AutoIt
    GUICreate("Test")
    GUISetState()
    GUIDelete() ; optional


    Getestet auf: Win 10 Pro 1909 (Build 18363.720)


    Viele Grüße

    Xenon

    Hi BugFix,


    sieht schick aus! Da haben wir ein gutes Beispiel, wo es wirklich Sinn macht, Execute zu verwenden! :thumbup:


    Das Script funktioniert soweit super, mir ist allerdings noch eine Kleinigkeit aufgefallen:

    Du ersetzt in deinen Funktionen per StringReplace einfach "it" durch den entsprechenden Wert. Damit zerschießt du ungewollt Funktionsaufrufe wie diesen hier:

    AutoIt
    _ArrayKeepItIf($aN, 'BitAnd(it, 1) = 0')

    Das "it" in BitAnd wird nämlich ebenfalls ersetzt!


    Meiner Recherche nach dürfte das aber nur eine handvoll Funktionen betreffen, die wirklich Sinn machen, darunter die Bit-Funktionen und StringIsDigit.


    Natürlich gäbe es einen Workaround à la

    AutoIt
    Func BAND($a, $b)
        Return BitAND($a, $b)
    EndFunc
    _ArrayKeepItIf($aN, 'BAND(it, 1) = 0')

    Aber vielleicht fällt dir ja eine andere Lösung ein. ;)

    Das gleiche Problem hätte man logischerweise auch, wenn man eigene Funktionen aufruft, die diese Zeichenfolge enthalten.


    Viele Grüße

    Xenon

    Hi JanausSm,


    wenn du eine Anfrage an den Webserver über HTTPS sendest, dann ist sowohl die Hin- als auch die Rückrichtung verschlüsselt. Also nicht nur deine Anfrage, sondern auch die zugehörige Antwort vom Webserver (z.B. per PHP echo).

    Normalerweise sollte das für die meisten Zwecke ausreichen, wenn du nicht noch zusätzliche Anforderungen hast, von denen wir nichts wissen?


    Nochmal zum allgemeinen Verständnis: Nur weil du dir eine HTTPS-Seite im Browser anschauen kannst, heißt das nicht, dass die Antwort unverschlüsselt übertragen wurde! Stattdessen übernimmt dein Browser im Hintergrund die Ver- und Entschlüsselung (bzw. ruft entsprechende Bibliotheken auf) und zeigt dir lediglich die entschlüsselten Daten an.


    Viele Grüße

    Xenon

    Hi alpines ,


    ich weiß, die letzte Antwort hier liegt schon eine Weile zurück, aber ich denke es passt trotzdem hier rein.

    Erst einmal ein herzliches Dankeschön für dieses Programm! :thumbup:8)

    Ich wollte das schon lange mal ausprobieren und habe mir nun endlich nach einigen Jahren doch noch ein zweites Numpad zugelegt. Deine Anwendung funktioniert auch immer noch zuverlässig.


    Allerdings hätte ich eine Frage:

    Weißt du, ob es eine Möglichkeit gibt, die Enter-Taste ebenfalls anders zu belegen? Das wäre ganz praktisch, aber standardmäßig scheint das mit dem Programm nicht zu gehen. Wie ich sehe, war auf deinem Numpad die Taste laut Aufklebern auch nicht umgemappt?


    Ich vermute mal, das basiert irgendwie auf dem gleichen Grund wie die Einschränkung bei der Standardfunktion HotKeySet?

    The following hotkeys cannot be set:


    NumPad's Enter Key: Instead, use {Enter} which captures both Enter keys on the keyboard.


    Hat jemand eine Idee für einen Workaround?

    Falls das Verwenden der Taste leider nicht möglich ist, weiß jemand, warum diese Taste von Windows so besonders behandelt wird? Das würde mich mal interessieren.


    Viele Grüße

    Xenon

    Ich hab das ganze mal etwas robuster gegen andere Fenster gemacht, die zum gleichen Zeitpunkt auftauchen...

    Das ist natürlich noch mal besser als die bisherige Version! Allerdings würde ich mich an dieser Stelle dann doch eher autoiter anschließen und dafür plädieren, selbst eine einfache GUI zusammenzubasteln oder eine passende UDF zu nutzen. Neben Hooks & Dll-Calls zusätzlich auch noch mit zufälligen Window-Titeln & co. herumzuhantieren macht das Ganze aus meiner Sicht noch unnötig komplexer als es ohnehin schon ist. Zum anderen wäre eine eigene GUI auch deutlich flexibler. Und die erwähnte UDF von Melba sieht auch vielversprechend aus, dann muss man nicht das Rad neu erfinden:


    PS: Es gibt dazu auch eine nette UDF: https://www.autoitscript.com/f…box-new-version-2-aug-18/

    Hi Bernhard,


    die Funktion _WinAPI_SetWIndowsHookEx($WH_CBT, ...) registriert deine Funktion "CbtHookProcMsgBox" als Callback.

    Der Parameter $WH_CBT bedeutet hierbei, dass diese Funktion in folgenden Fällen aufgerufen wird:

    The system calls a WH_CBT hook procedure before activating, creating, destroying, minimizing, maximizing, moving, or sizing a window; [...]


    Der Hook gilt für deine gesamte Anwendung und deshalb wird die Callback-Funktion auch aufgerufen, wenn (nach Schließen der MsgBox) die Main-GUI wieder aktiviert wird.

    Dann überschreibt _WinAPI_SetDlgItemText entsprechend (ungewollt) deine Buttontexte auf der Main-GUI.


    Um dies zu umgehen, fallen mir spontan zwei Workarounds ein:


    1. Die Texte (ja/nein/vielleicht) nur setzen, falls das aktive Fenster nicht die Main-GUI ist:


    Dazu muss einfach nur eine If-Bedingung im Programm eingefügt werden:

    Code
    If $wParam <> $hMainGUI Then
        _WinAPI_SetDlgItemText($wParam, 3, "Ja")
        _WinAPI_SetDlgItemText($wParam, 4, "Nein")
        _WinAPI_SetDlgItemText($wParam, 5, "Vielleicht")
    EndIf


    2. Den Hook nach dem Setzen der Texte in der MsgBox sofort wieder entfernen:


    Dazu muss lediglich die Zeile

    Code
    _WinAPI_UnhookWindowsHookEx($hHookMsgBox)


    an der ursprünglichen Stelle entfernt und stattdessen nach unten verschoben werden:

    Code
    ...
    _WinAPI_SetDlgItemText($wParam, 5, "Vielleicht")
    _WinAPI_UnhookWindowsHookEx($hHookMsgBox)            ; hier einfügen



    Meiner Ansicht nach dürfte Variante 2 die sauberere sein, aber die konkrete Umsetzung bleibt natürlich jedem selbst überlassen ;)


    Viele Grüße

    Xenon