Beiträge von misterspeed

Zitat von tuotuogou

übrigengs diese beiden Zeilen machen die Arbeit. ob die $msg=-7 zu prüfen ist, scheint unwichtig zu sein.

Nein. Bei mir verschwanden die Buttons noch wenn man das Fenster an den oberen Bildrand zieht, so dass unter Windows 7 das automatische Fenstervollbild eintritt und danach wieder zurückzieht, so dass es wieder Normalgröße hat. Die Konstanten für maximize, restore oder resize hatten in diesem speziellen Fall nicht funktioniert, daher hatte ich zusätzlich noch auf die msg -7 geprüft.

Der Vollständigkeit halber: Windows 7 Pro x64 aktueller Updatestand in Verbindung mit Autoit 3.3.6.1

Die Lösung ist dennoch nicht zufriedenstellend, denn eigentlich sollte ein redraw des Fensters auch über die entsprechenden winapi Funktionen auslösbar sein bzw. der Bug sollte garnicht erst auftreten.

Normalerweise sollte eine der beiden Funktionen das Problem lösen, funktioniert hier aber seltsamerweise nicht:

_WinAPI_UpdateWindow
_WinAPI_RedrawWindow

Hier ein Workaround, zwar nicht schön aber scheint zu helfen:

$msg=-7 ist im übrigen die Windowmessage die Auftritt wenn man das Fenster "anpackt", -8 wird ausgelöst wenn man das Fenster "loslässt". Keine Ahnung wie die zugehörigen Konstanten heißen, vermutlich drag and drop...

Zitat von PainTain

Aber für so eine Art Kopierschutz eignet sich AutoIt ja eigentlich garnicht, da eigentlich jeder das ganze dekompilieren kann.

Das trifft bei ausreichender Motivation auf so ziemlich jede Sprache zu. Nicht umsonst gibt es nahezu alle Programme und Spiele auch "für umsonst".

Mal vom Onlinezwang, Kopierschutz oder Lizenzmodellen abgesehen könnte man durch Nachladen von Code aber auch erweitertes Debugging zur Laufzeit realisieren. Ich habe soetwas selbst schon genutzt um mir zur Programmlaufzeit bei kompilierten Scripten Arrays oder Variablen ausgeben zu lassen. Das war notwendig weil der Fehler nur selten bei kompilierten Versionen auftrat, daher hatte ich mir diese Debug Funktionalität eingebaut um im Fehlerfall nachzusehen was nicht stimmt.

Man muss nicht immer sofort diverse Dinge unterstellen. Natürlich gibt es neben Trojanern auch legitime Gründe so vorzugehen. Man könnte darüber zum Beispiel einen Kopierschutz realisieren der auf eine bestehende Internetverbindung mit dem Lizenzserver angewiesen ist. Auch ein Lizenz / Upgrade Model mit erweiterten Funktionen für zahlende Nutzer wäre so realisierbar usw.

Ist es sinnvoll, zuverlässig genug oder eher schwachsinnig sowas zu tun? Das ist immernoch eine Frage die sich der Programmierer selbst stellen muss.

Zitat von kelevr

Kennt denn jemand noch eine bessere Methode?

Wie schon gesagt wurde. Du kennst nun beide Möglichkeiten um Autoitcode zur Laufzeit auszuführen oder zu interpretieren.

Natürlich gibt es noch etliche andere Möglichkeiten beliebigen Code nachzuladen, das hat dann aber kaum noch mit Autoit zu tun. Du könntest wie gesagt eine Kommandosprache entwickeln und über solche Konfigurations Dateien den Scriptverlauf beeinflußen, du könntest exe oder dll Dateien ausführen/laden und dir Schnittstellen zur Kommunikation mit diesen selbst geschriebenen Addons programmieren, du könntest inline Assembler nutzen und so weiter.

Ohne konkreten Anwendungsfall macht es aber keinen Sinn da weiter darüber zu reden, denn nur im konkreten Fall kann man dir sagen was geeignet ist oder was bei weitem zu umständlich bzw. wenig praktikabel wäre.

Zitat von kelevr

WIe müsste man das denn angehen?

Vielleicht erzählst du uns erstmal ein wenig von deinem Script. Was tut es wie sieht es derzeit aus und was willst du einbinden können bzw. was soll damit erreicht werden?

Deine Beispielschnippsel lassen bisher nicht wirklich erkennen wozu du überhaupt Autoitcode dynamisch parsen oder interpretieren musst. Wenn es nur um die Austauschbarkeit von Text innerhalb einer msgbox geht langt auch eine simple ini oder Text Datei, welche die Texte enthält. Autoitcode bräuchtest du dann überhaupt keinen in diesen externen Dateien.

Selbst wenn es über Texte in msgboxen hinausgehen sollte bietet sich ggf. immernoch eine eigene Dateistruktur / Zwischensprache an die dein Hauptscript auswerten kann um bestimmte Dinge variabel zu gestalten. Das gibt dir wesentlich mehr Kontrolle darüber was diese Zusatzanweisungen tun können.

Naja du musst eben die Zeilen splitten und einzeln interpretieren.

Hier deine Möglichkeiten:

fileread (in Verbindung mit) stringsplit
_filereadtoarray (im prinzip das gleiche wie oben, nur bequemer)
filereadline

Wie im Web üblich wirst du in der Regel LF als Zeilenumbruch auf Webseiten vorfinden. Das Notepad unter Windows zeigt dir diese Umbrüche aber nicht an und benötigt ein CRLF.

Die einfachste Lösung:

1. Verwende

inetread

, um den String der Webseite direkt in einer Variable zu erhalten
2. verwende

stringreplace

und ersetze

@LF

durch

@CRLF

3. Sofern überhaupt notwendig verwende

filewrite

um den bearbeiteten String in eine Datei zu schreiben

EDIT: Da war ich nen Tick zu langsam...

Zitat von Andy

In jedem zur EXE kompilierten AutoIt-Script befindet sich das Script und auch der Interpreter.
Somit kann der Interpreter jeden externen AutoIt-Source direkt aus der Datei ausführen....

[autoit]

Run('"' & @AutoItExe & '" /AutoIt3ExecuteScript "' & @ScriptDir & $Sourcefile & ".au3" & '"')

[/autoit]

Nicht ganz... Backslash vergessen

Run('"' & @AutoItExe & '" /AutoIt3ExecuteScript "' & @ScriptDir & '\' & $Sourcefile & ".au3" & '"')

Außerdem muss beachtet werden, dass die verwendeten Includes des Externen Scriptes vorhanden sein müssen, also sinnigerweise mitgeliefert und korrekt mit relativem Pfad im externen Script referenziert werden müssen. Werden nur native Autoitfunktionen ohne UDF Funktionen benutzt klappt das aber ohne weiteres. Ein kleiner Fallstrick besteht evtl. noch wenn das externe Script nur 64bit kompatibel ist (z.B.Nutzung einer 64bit dll), das Hauptscript aber den 32bit Interpreter enthält. Das selbe Problem besteht natürlich auch umgekehrt.

Der Thread Autor sprach aber eigentlich mehr vom interpretieren einzelner injizierte Code Abschnitte und nicht von kompletten Scripten. Das kann man durch die vorsichtige Nutzung dieser Funktionen erreichen:

fileread()
isdeclared()
eval()
assign()
execute()
call()

Die Wahrscheinlichkeit von Scriptabstürzen steigt aber gewaltig wenn man hier nicht sehr gut prüft was da eigentlich eingebunden werden soll.

Bevorzugt solltest du

controlsettext(...)
; oder
controlsend(...)

verwenden, da das bedeutend zuverlässiger arbeitet als send(). Gerade wenn man Autoit beruflich nutzt sollte man Wert auf Zuverlässigkeit legen.

Ich habe ehrlich gesagt keinen Bock mir das zugehörige FTP Script drumherum zu schreiben nur um dein Problem mit meinem FTP Server nachvollziehen zu können. Allerdings ergibt dein Beispiel Timestamp auch bei mir ein "00" für den Sekundenanteil, ändert man einfach die letzte Ziffer zu einer "5" erhält man mit Autoit Version 3.3.6.1 aber "09" für die Sekunden. Prinzipiell liefert die Funktion unter meiner etwas angestaubten Autoit Version also durchaus auch andere Werte. Ich würde an deiner Stelle daher mal eine etwas stabilere "stable" wie z.B. die 3.3.8.1 testen. Würde mich jedenfalls nicht überraschen wenn noch ein weiterer Bug in der derzeit aktuellen stable schlummert.

Microsoft API für Sensoren aller Art: http://msdn.microsoft.com/en-us/library/…v=vs.85%29.aspx

Google findet auch noch etwas namens "Validity Extended API"...

Ob du Autoit spezifischen code findest keine Ahnung, aber wenn du dir die sensors api anschaust kannst du mit Sicherheit auch nach Autoit in Verbindung mit den genutzten DLLs suchen und wirst evtl. fündig.

Nunja die Hilfe von Autoit ist dein Freund, da findest du jedemenge Dinge die Autoit kann inklusive praktischen Beispielen.

Die primitivste und einfachste Lösung ist wohl die msgbox aus dem dortigen Beispiel durch ein

send(...)

zu ersetzen.

Send() schickt alle gewünschten Tastenbefehle an das gerade aktive Fenster/Control. Bei umfangreichen sends kann das aber auch gern mal schief gehen und in einem anderen Fenster landen, außerdem ist send nicht unbedingt schnell, aber letzlich für deine Aufgabe absolut ausreichend.

Etwas zuverlässiger wäre

controlsend()
;bzw.
controlsettext()

. Dazu benötigst du aber eindeutige Informationen über das Fenster und Control welches du ansprechen willst. Außerdem gibt es Programme die keine Standardcontrols verwenden. Diese Lösung ist also für eine dynamische und flexible Lösung wie du sie suchst eher nicht geeignet und sollte bevorzugt dann verwendet werden wenn du ein bestimmtes Programm steuern willst über das alle nötigen Informationen vorliegen.

Für Textausgaben gibt es neben msgboxen im übrigen noch jedemenge Alternativen, auch wenn das nun nichts mehr mit deinem Vorhaben zu tun hat:

consolewrite
stdinwrite
filewrite
iniwrite
traytip
splashtexton
; eigene gui mit labeln...

Und wie wäre es stattdessen mit den Funktionen der IE.au3 ? Die Seite hat mit Sicherheit einen refresh button den du mittels IE Funktionen klicken könntest, alternativ eben ein Klick auf irgendeinen Menüpunkt und wieder zurück um die Session aktiv zu halten.

Wie Bugfix schon sagte benötigst du einen Keyboard Hook um das umzusetzen. Ein Blick auf die hotstring.au3 sollte dir alles liefern um das gewünscht und von Bugfix näher beschriebene Vorhaben zu realisieren.

http://www.autoitscript.com/forum/topic/68…string-hotkeys/

Wo willst du solche Abkürzungen ersetzt haben? In einer eigenen GUI oder in x-beliebigen Programmen / einem bestimmten Programm? In einer eigenen GUI sollte das sehr einfach zu realiseren sein, bei externen Programmen könnte das aufwendiger werden. Vielleicht einfach mal ein AutoHotkey Beispiel posten in dem du diese Funktionalität nutzt?

Zitat von PainTain

Dann enhaelt $idButtons[0] das Handle des "PC1" - Button, $idButtons[1] das Handle des "PC2" - Button usw.

Bringt dir nur nix, weil bei dir alle Buttons an der selben Position sind und sich überlappen. Wenn man das dynamisch erstellt muss man natürlich auch noch die Position in Abhängigkeit des Schleifenzählers berechnen.

Also sowas in der Art:

$idButtons[$i-1] = GUICtrlCreateButton($f[$i], 20, 120 + ($i*60), 200, 40)

Ich würde mal sagen du solltest zunächst vernünftig Debuggen um den Fehler besser einzugrenzen bzw. sauber Programmieren und Fehler abfangen, damit es nicht zu kompletten Scriptabstürzen wie im Screenshot kommen kann:

Mit dem Errorcode kannst du dann zumindestens mit Sicherheit sagen ob es ein MCI Fehler (was auch immer das sein mag...) oder ein Problem beim Auffinden der Datei ist. Sollte letzteres zutreffen liegt vermutlich wirklich ein Problem mit dem Pfad, dem Dateinamen oder den Zugriffsrechten des Benutzeraccounts vor. Hier wäre dann vielleicht im Vorfeld auch der Einsatz von

fileexists()

sinnvoll um spätere Fehler erst garnicht entstehen zu lassen.

Was den potentiellen MCI Fehler anbelangt hilft evtl. ein Blick in die verwendete UDF Funktion oder google (ich vermute dieser Fehler deutet auf ein Problem mit der Datei oder dem Dateiformat ansich hin). WAV ist nicht immer gleich WAV, es gibt die unterschiedlichsten Codierungen für wav Dateien. Möglicherweise werden nicht alle Arten von _soundopen() unterstützt.

Zitat von GtaSpider

Nun die Frage: Gibt's sowas auch für die FileRead Funktion? Die CommUDF arbeitet ja mit CreateFile/FileRead. Gibt es eine Funktion in der kernel dll, die mir bescheid gibt, sobald etwas empfangen wurde?

Keine Ahnung ob ich dich richtig verstanden habe, aber wenn du eine Möglichkeit suchst dich vom Betriebssystem über Dateisystemänderungen informieren zu lassen hilft dir vielleicht das hier weiter:

https://autoit.de/index.php?page…6561#post356561

Ich würde der Funktion aber einen anderen Namen geben, denn wenn du für etwas anderes nochmal die file.au3 einbinden musst wirst du vermutlich Probleme bekommen wenn du eine eigene Funktion mit gleichem Namen deklariert hast.