Der Downloadlink funktioniert bei mir weder im Firefox noch im IE. Da poppt nur ein leeres Fenster auf. ![]()
Beiträge von misterspeed
-
-
Welches Datum und Uhrzeit Fenster? Wenn du hier Hilfe erwartest wäre zumindestens mal ein Link zu diesem Setup sinnvoll oder alternativ auch mal ein au3info summary log des Fensters/Controls das du manipulieren willst.
-
Wenn dein Problem gelöst ist bitte noch dein 1. Posting editieren und das Thread Präfix von "offen" auf "gelöst" ändern.
-
1. Dein Fehler bezieht sich auf eine Scriptzeile die du garnicht gepostet hast
[autoit]
2. Verwende bitte das Autoit-Code Symbol um Autoit Quellcode zu posten -->
3. Die Fehlermeldung ist doch eindeutig. Du verwendest in der Zeile die Variable $x2 ohne ihr vorher einen Wert zugewiesen zu haben bzw. sie zumindestens deklariert zu haben.
[/autoit][autoit][/autoit][autoit]
; Deklaration einer Variable:
Global $variable ; für globale, also funktionsübergreifende Variablen
Local $variable ; für lokale Variablen innerhalb eigener Funktionen
Dim $variable ; Autoit entscheidet automatisch ob Global oder Local; Wertzuweisung (Initialisierung) einer Variable:
[/autoit][autoit][/autoit][autoit]
$variable = 123 ; variable ist so automatisch auch deklariert, es empfhielt sich aber dennoch die Deklaration selbst vorzunehmen, da du so auch den Kontext festlegen kannst, also Global oder Local; Deklaration plus Initialisierung:
[/autoit]
Global $variable = 123
;...Findest du im übrigen auch alles in der Hilfe von Autoit.
-
Ok dann nehme ich das zurück. Hex-Schreibweise entspricht wohl einem Integer:
Zitat
Integer (ganze Zahlen) können gleichwohl in hexadezimaler Schreibweise repräsentiert werden, dem Integer voranstellend 0x wie in 0x409 oder 0x4fff (wenn Hex-Notation genutzt wird sind nur 32-bit Zahlen gültig). -
Naja ich würde mal vermuten es liegt an deinem Datentyp von $color. Ich arbeite zwar normal nicht mit dlls, aber du verwendest in deiner Funktion die den dllcall macht "int" als Datentyp, übergibst aber für $color einen hex-wert.
-
Und nun? Dein Script ist unvollständig. Woher sollen wir wissen was deine ominöse API.dll tut. Vermutlich hast du auch noch Autoit Code unterschlagen, denn ich sehe z.B. keine Möglichkeit das Script überhaupt zu beenden. Ein dllclose() fehlt btw auch und sollte grundsätzlich gemacht werden wenn man mit dlls arbeitet.
-
Unsinn, warum sollte controlClick das nicht erlauben, genau dafür ist es da.
Beispiel:
myTool.au3
Spoiler anzeigen
[autoit]
[/autoit] [autoit][/autoit] [autoit]
#include <ButtonConstants.au3>
#include <GUIConstantsEx.au3>
#include <WindowsConstants.au3>
#Region ### START Koda GUI section ### Form=
$Form1 = GUICreate("MyTool", 451, 191, 192, 124)
$Button1 = GUICtrlCreateButton("installieren", 160, 72, 75, 25)
GUISetState(@SW_SHOW)
#EndRegion ### END Koda GUI section ###While 1
[/autoit] [autoit][/autoit] [autoit][/autoit] [autoit]
$nMsg = GUIGetMsg()
Switch $nMsg
Case $GUI_EVENT_CLOSE
Exit
Case $Button1
install()
EndSwitch
WEndFunc install()
[/autoit] [autoit][/autoit] [autoit]
run(@ScriptDir & "\setup.exe") ; vorher setup.au3 kompilieren...
Do
Sleep(10)
Until WinExists("Setup Window blabla")
WinSetState("Setup Window blabla","",@SW_HIDE)Sleep(2000) ; nur zu demo zwecken
[/autoit] [autoit][/autoit] [autoit]ControlClick("Setup Window blabla","","[CLASS:Button; INSTANCE:1]") ; 1. checkbox anhaken
[/autoit] [autoit][/autoit] [autoit]
ControlSetText("Setup Window blabla","","[CLASS:Edit; INSTANCE:1]","neuer pfad") ; pfad ändern
Sleep(10) ; setup braucht kurz zeit um den button zu aktivieren, sonst kann er nicht geklickt werden
ControlClick("Setup Window blabla","","[CLASS:Button; INSTANCE:2]") ; weiter button klickenSleep(2000) ; nur zu demo zwecken
[/autoit]
WinSetState("Setup Window blabla","",@SW_SHOW) ; sichtbar machen, siehe da alles wurde korrekt gesetzt
EndFuncsetup.au3
Spoiler anzeigen
[autoit]
[/autoit] [autoit][/autoit] [autoit]
#include <ButtonConstants.au3>
#include <EditConstants.au3>
#include <GUIConstantsEx.au3>
#include <StaticConstants.au3>
#include <WindowsConstants.au3>
#Region ### START Koda GUI section ### Form=
$Form1 = GUICreate("Setup Window blabla", 373, 259, 192, 124)
$Checkbox1 = GUICtrlCreateCheckbox("option 1", 120, 72, 97, 17)
$Button1 = GUICtrlCreateButton("weiter", 112, 192, 75, 25)
GUICtrlSetState($Button1, $GUI_DISABLE)
$Checkbox2 = GUICtrlCreateCheckbox("option 2", 120, 104, 97, 17)
$inputPath = GUICtrlCreateInput("bitte pfad eingeben", 112, 144, 121, 21)
$Label1 = GUICtrlCreateLabel("OK", 256, 144, 19, 17)
GUICtrlSetState($Label1,$GUI_HIDE)
GUISetState(@SW_SHOW)
#EndRegion ### END Koda GUI section ###While 1
[/autoit] [autoit][/autoit] [autoit]
$nMsg = GUIGetMsg()
Switch $nMsg
Case $GUI_EVENT_CLOSE
Exit
case $Button1
MsgBox(0,"setup msg","installation fertig!")
EndSwitchIf GUICtrlRead($inputPath) <> "bitte pfad eingeben" Then
[/autoit] [autoit][/autoit] [autoit][/autoit] [autoit]
If BitAND(GUICtrlGetState($Button1), $GUI_DISABLE) = $GUI_DISABLE Then
GUICtrlSetState($Button1,$GUI_ENABLE)
GUICtrlSetState($Label1,$GUI_SHOW)
EndIf
EndIfWEnd
[/autoit] [autoit][/autoit] [autoit][/autoit] -
Naja du musst dich schon entscheiden ob du den onevent mode oder msgloop mode verwenden willst. Beides zusammen geht nicht.
Im Beispiel hier findest du ein Script, das im onevent mode arbeitet: http://translation.autoit.de/onlinehilfe/fu…lSetOnEvent.htmwichtig wäre z.B. das hier am Anfang deines Scriptes:
[autoit]
[/autoit]
Opt("GUIOnEventMode", 1) -
Ahja sofern du nur prüfen willst ob und welche Parameter die CLI.exe an die CCC.exe übergibt kannst du auch eine eigene CCC.exe schreiben die dir ausgibt mit welchen Parametern sie gestartet wird und die originale ccc.exe damit temporär ersetzen. Das liefert dir zumindestens die verwendeten Parameter. Ob die CLI.exe noch weitere "wichtige" Dinge tut kannst du so aber leider nicht prüfen.
EDIT:
Oder du machst das zur dauerhaften Lösung.
Du rufst "cli.exe start CCC" mit sw_hide auf, dadurch wird dann deine eigene CCC.exe gestartet und darüber startest du dann die originale ccc.exe mit sw_hide und den empfangenen Parametern. Also eine Art Proxy zwischen CLI.exe und originaler CCC.exe
Problem1: Sofern ein Anwender das CCC sichtbar starten will wird er das nicht mehr können. Dafür lässt sich aber evtl. auch eine Lösung finden, z.B. eine etwas intelligentere fake ccc.exe, die unterscheiden kann ob sichtbar oder unsichtbar gestartet werden soll.
Problem2: Updates des Treibers könnten deine fake ccc.exe evtl. überschreibenBeide Probleme könnte man in den Griff bekommen wenn man so vorgeht:
1. Main Script für autostart ordner
- benennt originale ccc.exe um nach ccc_org.exe
- kopiert eigene ccc.exe in den richtigen ordner
- startet CLI.exe
- wartet bis sich eigene ccc.exe gelöscht hat
- kopiert ccc_org.exe nach ccc.exe
- jeder weitere Aufruf der normalen Verknüpfung startet jetzt wieder die originale ccc.exe, somit sichtbar für den benutzer
- updates machen keine Probleme, weil die fake ccc.exe immer beim login von einem sicheren Ort aus kopiert wird
2. eigene ccc.exe
- liest $cmdlineraw
- startet ccc_org.exe $cmdlineraw mit @sw_hide
- löscht sich selbst
Problem 3: Möglicherweise unterbindet UAC oder die Benutzergruppe des Accounts, dass dein Script im Programmordner Dateien löschen/umbenennen/kopieren kann. Hier müsstest du dann ggf. entsprechende Dateizugriffsrechte vergeben.
-
Da es vermutlich nicht ganz einfach ist rauszufinden was die CLI.exe genau tut, ausser das eigentliche Control Center zu starten führt vermutlich kein weg daran vorbei das anschließend erscheinende Control Center Fenster anhand des Fenstertitels sofort wieder mit winsetstate(...) unsichtbar zu machen. Dabei wird sich ein kurzes aufblitzen nicht vermeiden lassen.
Alternativ würde ich einfach mal den ATI Support zur Aufgabe der CLI.exe befragen um ggf. die darin enthaltenen Funktionen zum Control Center Start selbst umzusetzen. Ansonsten eben mal den direkten Start der CCC.exe ausprobieren und schauen ob das Verhalten auch ohne "CLI.exe Start..." normal ist.
-
Aso noch eine Anregung bezüglich meinem Punkt 5 (Startparameter):
Ich finde es in Scite lästig, dass ich keine Möglichkeit habe Parameter pro Script zu speichern. Bedeutet konkret, dass sich Scite immer die zuletzt verwendeten Parameter merkt. Arbeite ich nun an einem anderen Script muss ich die Defaultparameter zum Testen neu eintippen. Sehr lästig, wenn man zum Testen öffter zwischen beiden Scripten wechseln muss.
Was ich mir also wünschen würde wäre entweder eine Historie in der IDE selbst, die alle Parameter die ich jemals verwendet habe in auswählbaren Listen speichert (bevorzugt in Verbindung mit dem Scriptnamen), oder Alternativ das automatische einfügen einer Kommentarsektion im jeweiligen Quellcode, welche sofern vorhanden ausgelesen wird um die Startparameter festzulegen. So könnte man Änderungen an den Testparametern direkt im Quellcode machen. Was nun besser oder einfacher umzusetzen ist... keine Ahnung.
Die Variante mit der Kommentar-Sektion hätte den Vorteil, dass die benötigten Parameter auch gleich dokumentiert wären. Problematisch wäre hingegen, dass das Parsing dieser Sektion bei manuellen edits evtl. fehlschlagen könnte.
Danke für den Tipp, kannte ich noch nicht. Schau ich mir bei Gelegenheit mal an.
-
Nein. Welchen Sinn hätte die Sperre durch Windows dann noch? Davon ab kann Windows ja noch nichtmal wissen mit welchem der angemeldeten Benutzeraccounts die Tastenkombination verbunden sein soll, es ist schliesslich möglich, dass mehrere Benutzer angemeldet sind.
Grundsätzlich bestünde aber die Möglichkeit übers Netzwerk auf Serverdienste zuzugreifen, welche auf einem der angemeldeten Benutzeraccounts laufen. Du könntest also einen Server auf TCP oder UDP Basis auf dem System laufen lassen und dann aus der Ferne ggf. darüber auch Prozesse auf den Benutzeraccounts starten. Sehen wirst du GUI technisch allerdings erst etwas davon, wenn der Account entsperrt wird. Anstelle eines eigenen Servers genügt btw. auch das Aktivieren des Remotedesktops. Hier kann man ebenfalls per Consolenbefehle Prozesse auf dem Zielsystem starten. Vermutlich ging es dir aber nicht um die Fernadministration. -
Ihr müsst eine eigene INI machen und die dann ins Internet stellen (Zeile 31). Die INI schaut so aus:
Öhm nicht dein Ernst oder? Findest du es wirklich sinnvoll FTP Daten im Klartext schutzlos ins Internet zu stellen, nur damit das eigene Programm sich diese Zugangsdaten wieder runterladen kann? Warum speicherst du die Daten dann nicht gleich lokal auf der Festplatte des Nutzers? Wozu der Umweg über einen Webspace, der von jedem ausgelesen werden kann?
-
Da James, falls es bei dir tatsächlich nicht soweit kommt. Zuerst sollte notepad starten und sobald man die Leertaste drückt erscheint das Spiel. Leertaste gedrückt halten um den Hellikopter nach oben zu lenken, Leertaste loslassen um nach unten zu steuern.
-
Ja das Script von Mat hat einige Warnings und Fehler in Scite und lässt sich dort garnicht starten. Der Start über den Explorer funktioniert bei mir aber trotz dieser Fehler, abgestürzt wie auf deinem Screen ist es bei mir nicht. Trotz diesem kleinen faux pas ist Mat für mich der Gewinner. Schade, dass man nur eine Stimme hat, denn Wambo hätte meiner Meinung nach ebenfalls eine Stimme von mir verdient, alleine schon für die kreative Idee ein Spiel innerhalb von notepad laufen zu lassen. Die Steuerung war aber leider nicht die beste, da lief das Tetris viel besser.
James "Turing Maschine" hab ich mal ganz schnell wieder zur Seite gelegt, nachdem ich mich mit diesem Kram erst im Unterricht befassen musste. *hust*
Ansonsten sind natürlich alle Scripte klasse und ich finde es beeindruckend wie stark komprimiert man programmieren kann wenn man es darauf anlegt.
EDIT:
Wer auch immer die ZIP Archive erstellt hat... vielleicht das nächstemal darauf achten, dass keine __MACOSX Ordner drin sind.

-
Also sofern ich die derzeit aktuelle und richtige imagesearch.au3 gefunden habe wundert mich das nicht. Hier der problematische Abschnitt der UDF:
[autoit]
[/autoit][autoit][/autoit][autoit]
$result = DllCall("ImageSearchDLL.dll","str","ImageSearch","int",$x1,"int",$y1,"int",$right,"int",$bottom,"str",$findImage); If error exit
[/autoit]
if $result[0]="0" then return 0So was kann hier also schiefgehn? Angenommen die DLL ist nicht vorhanden, dann gibt die Funktion DLLCall kein Array zurück, sondern setzt nur @error. Prüft man nun ob Index 0 des Arrays 0 ist, was durchaus passieren kann wenn eben kein Bild gefunden wird, dann stürzt das Script hier ab, weil $return eben garkein Array ist. In der UDF fehlt also eine vorangestellte Prüfung ob die DLL existiert oder alternativ müsste man nach dem DLLcall auf @error prüfen bevor man mit dem Ergebnis Array arbeitet.
Möglicherweise gibt es aber längst eine aktuellere Fassung der UDF, bin nur dem ersten Google Treffer gefolgt. Wie dem auch sei es ist davon auszugehen, dass du schlichtweg vergessen hast die DLL Datei mitzuliefern.
Davon mal ab... wozu zum Henker braucht man die Funktion _imagesearch überhaupt? Ich sehe keinen sinnvollen Einsatzzweck dafür.
-
Deine Methode hat aber den Nachteil, das das Script ansich alleine lauffähig sein muss. Handelt es sich nur um eine Funktionssammlung die z.B. globale Variablen des Masterscripts beeinflussen oder andere Funktionen des Masterscipts nutzen soll, dann wird das so nichts helfen.
-
Du könntest aber evtl. execute() nutzen um einzelne Code Zeilen zur Laufzeit zu testen. Theoretisch sollte es so auch machbar sein einem Button zur Laufzeit eine andere Funktion zuzuweisen, die au3 Datei einlesen und dessen Inhalt Zeile für Zeile ausführen kann. Komplexeren Code wie Schleifen wirst du so aber wohl nur ausgeführt bekommen wenn du dir eine entsprechende Interpreter Funktion baust, die das ganze in separate Execute Statements wandelt. Sofern es sowas in der Art nicht schon irgendwo gibt halte ich den Aufwand allerdings für viel zu hoch. Da ist es sehr viel einfachher einfach das aktualisierte Script neu auszuführen.
-
1. "Alle Tabs schliessen" fehlt (alle speichern gibt es...)
2. Verhalten bei vielen offenen Tabs- getestet mit isn sourcen (include ordner)
- bei öffnen von vielen Scripten in kurzer zeit hängt sich Programm nach einer weile auf bzw hat lange Zeit volle CPU Auslastung und reagiert erstmal nicht mehr
- funktioniert nach einer halben ewigkeit wieder
- ab 29(sollten sicher 30 sein oder?) Tabs Fehlermeldung... "zuviele tabs..."
- folgt man dem hinweis die tabs zu schliessen (roter button) stürzt das script ab (array fehler), siehe screenshot. Fehler ist reproduzierbar und tritt immer auf wenn max. Tab Anzahl erreicht.
[Blockierte Grafik: http://i.imgur.com/2X6qs2t.png]
Lösung für die Performance Probleme könnte das Auslagern einiger zeitintensiven Dinge in externe helper Scripte sein. Dadurch kann man mehr als einen CPU Kern auslasten und so letzlich Multithreading realisieren. Das sorgt zwar auch für Performance Einbußen, weil das Hauptprogramm regelmässig Daten austauschen muss, aber letzlich kann man so einiges rausholen. So könnte man zum Beispiel problemlos viele große Scripte zeitgleich öffnen und im Hintergrund die Variablen Listen und co, zusammenstellen lassen. Theoretisch kann man das externe Script sogar veranlassen die Hauptgui über control Funktionen zu aktualisieren, so mach ich das in einem meiner Scripte.