Beiträge von misterspeed

Zitat von alpines

Vielleicht bringt der FileHeader der Bitmap das Ausleseverfahren durcheinander?

Hab mir das nie angeschaut, weil ich kein persönliches Interesse daran habe. Aber falls dem so sein sollte wäre es z.B. möglich eine base64 (De)Kodierung für sämtliche zu speichernden Daten zu verwenden. Dadurch sollten Konflikte komplett ausgeschlossen sein. Das geht dann aber halt zu lasten der Performance und Speicherplatzeffizienz.

Grundsätzlich sollte man auch die Windows Version erwähnen um die es überhaupt geht. Taskmanager ist nicht gleich Taskmanager, da gibt es genügend Unterschiede von Windows XP bis 10.

Manipulationen des Taskmanagers sollte man hier außerdem nicht allzu detailiert behandeln, da dies auch ganz gut zum Verstecken der eigenen (Schad-)Software mißbraucht werden kann.

Wie schaut das eigentlich bei Kopiervorängen via SMB von NTFS auf NTFS aus? Könnte mir vorstellen, dass die zusätzlichen Metadaten hier ebenfalls verloren gehen. Hintergrund ist, dass man im geschäftlichen Umfeld wohl sehr sicher auch eine Backuplösung einsetzt. Wenn die Metadaten eine wichtige Rolle spielen sollte man hier sehr gut prüfen was im Falle eines Serverausfalls passiert und ob die Daten aus dem Backup vollständig wiederhergestellt werden können.

Würd da mal ein 32/64bit Problem vermuten. Da dein Excel vermutlich 32bit ist würde ich sicherstellen, dass dein Script ebenfalls als 32bit Variante kompiliert wird.

Einfach ausprobieren?

#Include <Misc.au3>

While 1
    For $i = 1 to 255
        $key =Hex($i,2)
        If _IsPressed($key) Then
            ConsoleWrite($i & " = " & $key & '("' & Chr($i) & '")'  & @CRLF)
            Sleep(100)
        EndIf
    Next
WEnd

Ergibt bei mir für "<" den Integerwert 226 bzw. in HEX "E2"
Allerdings ergibt die Ausgabe mit Chr() ein eher kryptisches "ä". Sollte für dich aber keine Rolle spielen weil du nur auf den Tastendruck reagieren willst.

Die Frage ist... was willst du mit der ControlD tun? Es gibt bereits fertige Autoit Funktionen um Buttons in einer fremden GUI anzusteuern. Hier kann denke ich auch ein Buttontext als Suchattribut verwendet werden.

EDIT: da war Alpines schneller...

Naja warten wir mal aufs Script...

Ja aber was hat dein Client davon? Der Server ist der einzige der die SocketID des jeweiligen clients kennen muss, also speichert man das sinnvollerweise im Server gleich ab sobald ein neuer Client mit tcpaccept angenommen wird. Sich die ID nochmal hin und her zu schicken macht wenig Sinn.

Naja gibt ja etliche Möglichkeiten dein Hauptproblem zu lösen oder zu umgehen.

1. Warum soll die Webseite nicht mit dem IE kompatiblel sein und die IE.au3 somit ausscheiden?

2. Da du von einer DB sprachst... wäre es nicht evtl. sinnvoller die Datensätze direkt über eine benutzerfreundlichere Autoit GUI manuell vom Nutzer in die DB eintragen zu lassen? Für die meisten Datenbanken findest du passende Autoit UDFs.

3. Du könntest deinem Script eine alte Firefox Portable Instanz beilegen, welche mit dem Addon MozRepl kompatibel ist und nur diese eigene kompatible FF Instanz für alle Webseiteninteraktionen nutzen. Das habe ich selbst lange Zeit in einem meiner Scripte gemacht, weil diverse FF Updates immer wieder Probleme bereitet haben und ich so gewährleisten konnte, dass sich am Browser nichts ändert (deaktivierte Updates der Portable Version)

4. Viel effizienter und schneller ist die Kommunikation via winhttp.au3. Hierbei sendest du direkt die Pakete an die Webseite, welcher dein Browser beim Absenden der Formulare senden würde. Nachteil hierbei ist aber, dass du keine sichtbare Browserinstanz für den Anwender hast, sprich alle GUI Möglichkeiten müssen wie bei Vorschlag 2 von dir in Autoit bereitgestellt werden, damit der Benutzer die Datensätze in Autoit anlegen kann. Der Unterschied zu Vorschlag 2 wäre, dass du keinen direkten DB Zugriff im Script brauchst, sondern nur gültige Anmeldedaten für die Webseite.

5. Optimalerweise bietet die Webanwendung eine Web API an, in diesem Fall ist Lösung 4 sogar noch einfacher und zuverlässiger umzusetzen

Lösung 1 ist vermutlich am schnellsten und leichtesten umsetzbar, danach folgt Lösung 3. Lösung 2, 4 und 5 sind am performantesten, allerdings auch aufwendig umzusetzen und ggf. aufgrund der IT Sicherheit nicht realisierbar.

Alle Lösungen sind jedenfalls zuverlässiger als Mausklicks anhand von Fensterkoordinaten.

Zitat von AutoMit

Auch das geht leider nicht, weil meine Parameter länger sind, als es die Zeichenkettelänge einer Verknüpfung zulässt. Daher liegen diese Informationen im Kommentar der Verknüpfung. Diese kann ich mit AutoIt auslesen. Aber nur, wenn ich weiß, wo die Verknüpfung liegt.

Nur mal am Rande... wenn man wirklich sehr viele und umfangreiche Parameter benötigt bietet es sich an diese Informationen in eine Parameterdatei auszulagern und nur den Pfad zur Parameterdatei als Parameter beim Aufruf zu nutzen. So machen das alle gängigen cmdline Tools die sehr umfangreich/komplex sind. Damit sollte dann auch dein Problem gelöst sein, denn du musst nicht mehr relevante Informationen in das Kommentarfeld deiner Verknüpfung auslagern.

Zitat von Bitnugger

Hier hast du übrigens eine vergleichbare Frage hestellt...

Danke... wusste doch er hat das schonmal gefragt.

Zitat von AutoMit

Wenn sowas möglich ist, dann bietet Windows sicherlich über irgendein Mittel auch den Zugriff auf die zugrundeliegende Verknüpfung an.

Nein. Wenn du eine Verknüpfung ausführst wird schlichtergreifend der Windowsinterpreter für exe Dateien gestartet und öffnet dann eben die definierte Datei mit den entsprechenden Parametern und ggf. Arbeitsverzeichnis und Kompatibilitätsmodus. Der Speicherort der Verknüpfung ist dabei völlig irrelevant und wird dem zu startenden Programm daher auch nicht mitgeteilt. Der einzige der Kenntnis von der Verknüpfung hat ist evtl. der Windows Interpreter, welcher die benötigten Verknüpfungsinformationen ermittelt um die EXE Datei entsprechend auszuführen. Diese Information wird aber mit Sicherheit nirgendwo gespeichert oder via API zugänglich gemacht, da eben völlig irrelevant für irgendjemand anderen.

Im Gegensatz dazu sind Informationen über den Parent- oder Childprozess durchaus relevant, weil unter anderem die Berechtigungsstufe (Adminrechte?) an die Child Prozesse weitergereicht werden. Desweiteren ist es Üblich, dass ein Prozess welcher einen anderen startet mit diesem kommuniziert oder diesen zumindestens überwacht.

Verstehe den Sinn dahinter absolut nicht.

Warum spielt es eine Rolle wo die Verknüpfung nun liegt?

Was machst du wenn der Anwender garkeine Verknüpfung verwendet um die au3 auszuführen?

Für Windows macht es jedenfalls absolut keinen Unterschied ob du "Start->Ausführen", "cmd.exe", eine Verknüpfung auf dem Desktop oder eine Verknüpfung die sonst wo liegt verwendest um die autoit.exe mit Parameter zu starten.

Wenn du das unbedingt haben musst, dann pass die zu überwachenden Verknüpfungen halt an und pack als zweiten Parameter noch den Pfad zur Verknüpfung selbst mit rein. Der zweite angegebene Parameter kann im Script dann z.B. mit der globalen Autoit Standard Variable $cmdlineraw oder dem Array $cmdline[...] abgefragt werden. (Siehe auch Autoithilfe bzgl. "Command Line Parameters")

Seh jetzt auch nicht das Problem darin. Ja dein Array könnte aufgrund weiterer Events während der Abarbeitung der zuvor erfassten Datei(en) aktualisiert werden. Warum sollte das Konsequenzen haben? Wenn deine Funktion nicht damit klar kommt, wenn weitere Dateien im Array auftauchen dann arbeite mit einer Kopie des "alten" Standes als die Funktion aufgerufen wurde. Alle weiteren Dateien kommen dann erst zum Tragen wenn deine Endlosschleife erneut Dateien im Array vorfindet und die Abarbeitung ein weiteres Mal aufruft. Alternativ gibst du immer nur den Dateinamen einer Datei an die Abarbeitungsfunktion heraus (siehe unten).

Beispiel:

#include <array.au3>

Global $aFiles[1]= ["Pfad"]

HotKeySet("{ESC}", "myEvent")

Do
    If UBound($aFiles)>1 Then
        abarbeiten($aFiles[1])
        ConsoleWrite("Arrayzeile " & $aFiles[1] & " wird nun entfernt." & @CRLF)
        _ArrayDelete($aFiles,1)
    EndIf
Until 0

Func myEvent()
    _ArrayAdd($aFiles,"C:\test\" & Random(100,999,1) & ".pdf")

    ;debug:
    Local $sDebug = "----------" & @CRLF & "Arrayinhalt:" & @CRLF & "----------"
    For $i = 0 To UBound($aFiles)-1
        $sDebug = $sDebug & @CRLF & "$afiles[" & $i & "]=" & $afiles[$i]
    Next
    ConsoleWrite($sDebug & @CRLF)
EndFunc

Func abarbeiten($sPath)
    ; filemove
    ; mach irgendwas...
    ; fertig
    ConsoleWrite("abarbeiten() wurde mit pfad " & $sPath & " aufgerufen." & @CRLF)
    Sleep(10000)
EndFunc

EDIT:

Wie du selbst festgestellt hast ist das Event Abschalten keine Lösung, denn dann würdest du neue Dateien evtl. verpassen.

Jenachdem wie du dein Script aufgebaut hast kann das durchaus zu Problemen führen. Deswegen macht in meinem Script die Eventfunktion lediglich einen neuen Eintrag in einem Array. In der Hauptschleife wird dann geprüft ob unbearbeitete Dateien im Array vermerkt sind und diese werden dann nacheinander abgearbeitet.

EDIT: Ob runwait unterbrechbar ist kann ich dir nicht sagen. Die langen Sleeps oben im Beispielscript werden aber scheinbar unterbrochen, da man ESC sehr schnell in Folge drücken kann. Aber selbst wenn auch runwait unterbrochen werden kann ist das kein Problem wenn du wie oben beschrieben vorgehst.

Das ist so ziemlich das selbe, als ob du innerhalb der Schleife einen eigenen Funktionsaufruf machen würdest. Das eintretende Event führt automatisch zu einem JUMP zur definierten Funktion und danach gehts wieder dort weiter wo unterbrochen wurde. Das selbe Prinzip wird bei der Funktion adlibregister oder hotkeyset angewandt.

Beispiel mit Hotkeyset:

HotKeySet("{ESC}", "testevent")

Do
    ConsoleWrite("Anfang der Schleife..." & @CRLF)
    Sleep(3000)
    eigenefunktion("Funktionsaufruf in der Schleife...")
    Sleep(3000)
    ConsoleWrite("Ende der Schleife..." & @CRLF)
    Sleep(3000)
Until 0 ; das ist eine endlosschleife

Func testevent()
    ConsoleWrite(@TAB & @TAB & "Eventcode wird ausgeführt!" & @CRLF)
EndFunc

Func eigenefunktion($sText)
    ConsoleWrite(@TAB & $sText & @CRLF)
    Sleep(3000)
    ConsoleWrite(@TAB & "Funktion eigenefunktion wird jetzt verlassen..." & @CRLF)
EndFunc

Jenachdem wann du ESC drückst wird das Script entweder innerhalb der Hauptschleife oder aber innerhalb deiner eigenen Funktion für die Ausführung der Eventfunktion unterbrochen.

Er hat doch oben im Spoiler "String" einen Teststring

Sollte mit GDI+ kein Problem sein. Hier hat sich jemand dran versucht einfachen Text auf ein Bild zu legen:

https://www.autoitscript.com/forum/topic/65…-text-to-image/

EDIT: Da war alpines wohl schneller...

Jupp dein Script sollte natürlich sicherstellen, dass nicht permanent zwischen den Stati hin und hergewechselt wird. Desweiteren sollte dein Script nur dann die Bild GUI aktualisieren, wenn sich etwas an der Kundennummer geändert hat (ansonsten könntest du ein Flackern des Bildes wahrnehmen). Ich würd außerdem nicht permanent neue Bildcontrols in der GUI erstellen, sondern den Inhalt des Controls ändern. Andernfalls hast du nach einiger Zeit hunderte oder tausende controls die übereinander liegen. Soweit ich weiß gibt es außerdem ein maximales Limit an controls, was dann zum Scriptabsturz oder eben zu keinen neuen controls mehr führt.

EDIT: Es schadet im Übrigen auch nicht vorher zu prüfen ob für die Kundennummer überhaupt ein Bild exisitert. Falls nicht kannst du ja z.B. ein Standardbild einblenden.