Beiträge von BugFix

    Ich finde es auch nicht verwerflich mit einer Kombination von RegEx und Stringfunktionen zu arbeiten. Ich hatte zu diesem Thema mal diese Funktion erstellt:

    Es ergibt doch keinen Sinn, an eine "DOS-Box" mühselig etwas mit Send zu übertragen.

    Eine Exe lässt sich im Hintergrund mit Run ausführen und die Ergebnisse können mit StdoutRead ausgelesen werden. StdinWrite erlaubt direktes Schreiben in die Konsole.

    Damit sind alle Grundlagen für die Umsetzung der Aufgabe vorhanden.

    Diese Punkte würden mich interessieren, gerne vorab auch als Konversation.

    Bitte ausschliesslich als Konversation. Wir hatten diesbezüglich lang und breit bei der Einführung der Regeln diskutiert. Und es gibt keinen Anlass zum Hinterfragen der Regeln.

    Falls du bis Freitag keine Lösung hast, pushe es dann nochmal. Bin bis dahin unterwegs und habe meine Skripte nicht bei. Bin der Meinung, etwas Ähnliches (Keyboard state abfragen/setzen) vor einigen Jahren mal umgesetzt zu haben. Würde mir das dann nochmal näher ansehen.

    Zitat von Muashi

    Die Laufvariable $i in einer For...Next-Schleife ist ja nicht deklarationspflichtig bzw. gilt automatisch als deklariert, selbst bei Opt('MustDeclareVars', 1) .

    (ich vermute mal, das war ursprünglich ein Bequemlichkeitsfeature)

    Nein, keine Bequemlichkeit. Zählervariablen werden üblicherweise durch Verwendung deklariert, da sie unabdingbarer Bestandteil der Schleife sind. In anderen Sprachen existiert i.A. die Zählervariable aber auch nur innerhalb der Schleife, in AutoIt lebt sie weiter. Das erscheint manchmal ganz praktisch, da ich z.B. bei Verlassen der Schleife durch bestimmte Bedingung, den Wert des Zählers bei Gültigkeit dieser Bedingung sofort greifbar habe ohne ihn einer vorab deklarierten Variablen zuweisen zu müssen. Das kann aber durchaus auch zu Fehlern führen (bedingte Ausführung von Schleifen in einem Level).

    Ich würde parallel einen "Erfolgs-Launcher" laufen lassen.

    Bevor Run(Irgendeine.exe) gestartet wird, übergibst du an den Launcher den Prozeßnamen, der existiert, wenn die Datei erfolgreich gestartet wurde. Im Hintergrund pollt der Launcher dann etwa alle 500ms und prüft die Prozess-List. Wurde ein Prozeß aus seiner Überwachungsliste gefunden, wird Erfolgs-Counter um 1 erhöht und der Eintrag aus der Überwachungsliste entfernt (optional zusätzlich Logeintrag).

    Nach Start des letzten Programms, wird ein MaxWait-Befehl übergeben (Einfach einen Fantasie-Dateinamen übergeben, z.B. "MaxWait.process") und bei Erscheinen dieses Dateinamens in der Überwachungsliste den Namen sofort entfernen und ein TimeOut laufen lassen. Ist nach Ablauf des TimeOut die Liste noch nicht leer, die Namen der nicht (erfolgreich) gestarteten Prozesse ausgeben.

    Du teilst die Anzahl der Listeneinträge durch die gewünschte Anzahl an Instanzen. Es ist eher unwahrscheinlich, dass dieses ein ganzzahliger Wert wird. Also musst du dich entscheiden, ob du die nächstgrößere oder -kleinere Ganzzahl verwenden möchtest (Ceiling / Floor). Die Anzahl der möglichen Prozesse brauchst du nicht in einer Schleife abarbeiten - das ergibt sich von selbst. Nehmen wir an du hast das Verarbeitungsskript kompiliert als "work.exe". Parameter-Aufruf wäre dann z.B. so:

    ShellExecute("work.exe", '"param string 1" "param string 2" "param string n"')


    In deinem Aufrufskript gehst du so vor:


    Das Verarbeitungsskript sollte kein Problem sein. Siehe hier.

    _WinAPI_RedrawWindow()


    Die Erklärung zu den $iFlags könnte m. E. etwas konkreter sein (mehr an den Inhalt von MSDN angelehnt), dann sind die Verwendungsmöglichkeiten etwas eindeutiger.

    Vor allem fehlen mir in der AutoIt-Hilfe (sowohl deutsch als auch englisch) die Gruppierungen der Flags und deren Beschreibung. Hier mal meine direkte Übersetzung aus MSDN. Evtl. ist es ja sinnvoll etwas zu übernehmen:

    Das Zugreifen auf Elemente in der Taskbar ist nicht so simpel, wie man denken mag. Ich dachte: Handle der Shell_TrayWnd abfragen - EnumChildWindows bringt die Subfenster - fertig.

    Das ist aber nur die halbe Wahrheit, denn wenn man nach der ChildEnumertion anschliessend das Parent abfragt, ist dies nur z.T. das Shell_TrayWnd. Teilweise sind die enthaltenen Fenster untereinander verbunden. Mit dem folgenden Skript bekommt man die tatsächliche Zuordnung:



    Um andere Instanzen mit Inhalt zu versorgen, musst du diese (kompilierte Datei, nicht Funktion) mit Parametern aufrufen.

    Ich würde so vorgehen:

    - Skript 1 (Aufrufskript):

    Liest Textdatei in Array, jede Zeile ein Eintrag. Iteriert durch das Array und fügt Parameterstrings zusammen: "Zeile 1" & "SPACE" & "Zeile 2" & ... - Sind 10 Parameter zusammengefügt wird das Verarbeitungsskript aufgerufen und der Parameterstring mit übergeben. Intern zurücksetzen Parameterstring und weiter durch Array iterieren usw. usf.


    - Skript 2 (Verarbeitungsskript):

    Arbeitet das Parameterarray ($CMDLINE) ab, mit dem von dir vorgesehenen Code.

    Was bitte soll ein CUI Fenster sein?

    Eine konsolenbasierte Anwendung verzichtet i. A. auf Fenster (das ist der Sinn einer CUI). Du kannst natürlich Fenster (GUI) auch hierbei erstellen und anzeigen, aber das ist vom Handling wie sonst auch.

    Aber ich weiß nicht genau wie ich VOR dem Where den Order by befehl ausführen soll.

    Gar nicht. Sortierung wird immer auf die Ergebnisse einer Abfrage angewendet. Wenn du also aus einer Teilmenge auswählen willst, musst du diese Teilmenge durch ein SubQuery erzeugen (wurde schon drauf hingewiesen).

    Oder, wenn das zu kompliziert wird, kannst du die Teilergebnisse auch in einer temporären Tabelle speichern und diese für die Folgeabfragen nutzen. Falls Der SQL-Dialekt Batch-Queries anbietet (nutze ich z.B. in Firebird SQL), werden diese temporären Tabellen auch nur im RAM direkt aus einer Abfrage erzeugt und bedürfen keiner weiteren Deklaration.

    Von "alles in die user.calltips" bin ich nicht so der Freund. Ich hab lieber für jede UDF ne eigene Datei.

    Du kannst für alles eigene Dateien erstellen und einfach in der SciTEUser.properties einfügen: import my.special.abbrev

    Ich handhabe das so, dass ich die entsprechenden Dateien an einem beliebigen Ort gespeichert habe. Um aber kein Pfadwirrwarr beim import zu haben, sind die Dateien per Hardlink auch im Pfad C:\Users\USER\AppData\Local\AutoIt v3\SciTE angelegt. Dort sucht ScITE standardmäßig - das import benötigt somit keine weitere Pfadangabe.

    Bezüglich zum GDI Input ist mir leider bisher keine verwendbare Alternative eingefallen.

    Wenn ich richtig verstanden habe, wolltest du dass der User einen Hotkey erstellen kann. Dazu brauchst du nicht wirklich die Tasten abfragen. Hier mal ein Lösungsansatz auf ganz triviale Art:

    Auswahl Sondertaste per Button, Zeichentaste per Eingabe ins Inputfeld.

    Das Problem ist jedoch, dass die Microsoft Funktion "KBDLLHOOKSTRUCT"

    ausschließlich "low-level" input events erkennt.

    vkCode für SHIFT: left=0xA0, right=0xA1, für ALT=0xA4

    Die Struktur speichert "flags" - und diese repräsentieren das Release der entsprechenden Tasten: 0x80= UP for 'normal' keys and left pairs, 0x81= UP for right pairs


    Deine Konstruktion ist natürlich wenig effizient mit den If-Statements. Das kannst du alles mit dem Hook abwickeln. Aber hier stoßen wir an die Grenzen unseres Supports: Keylogging ist nunmal nichts, was wir unterstützen wollen, die Möglichkeit des mIßbrauchs ist zu groß.