1. Dashboard
  2. Mitglieder
    1. Letzte Aktivitäten
    2. Benutzer online
    3. Team
    4. Mitgliedersuche
  3. Forenregeln
  4. Forum
    1. Unerledigte Themen
  • Anmelden
  • Registrieren
  • Suche
Alles
  • Alles
  • Artikel
  • Seiten
  • Forum
  • Erweiterte Suche
  1. AutoIt.de - Das deutschsprachige Forum.
  2. Mitglieder
  3. misterspeed

Beiträge von misterspeed

  • Fenster im Hintergrund bedienen

    • misterspeed
    • 10. März 2013 um 12:34

    Der Downloadlink funktioniert bei mir weder im Firefox noch im IE. Da poppt nur ein leeres Fenster auf. ?(

  • Fenster im Hintergrund bedienen

    • misterspeed
    • 9. März 2013 um 20:18

    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.

  • ImageSearch Error

    • misterspeed
    • 9. März 2013 um 20:13

    Wenn dein Problem gelöst ist bitte noch dein 1. Posting editieren und das Thread Präfix von "offen" auf "gelöst" ändern.

  • ImageSearch Error

    • misterspeed
    • 9. März 2013 um 18:10

    1. Dein Fehler bezieht sich auf eine Scriptzeile die du garnicht gepostet hast
    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]


    ; 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

    [/autoit][autoit][/autoit][autoit]

    ; Wertzuweisung (Initialisierung) einer Variable:
    $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

    [/autoit][autoit][/autoit][autoit]

    ; Deklaration plus Initialisierung:
    Global $variable = 123
    ;...

    [/autoit]

    Findest du im übrigen auch alles in der Hilfe von Autoit.

  • Nach (DLL-)Funktion -> Exit

    • misterspeed
    • 9. März 2013 um 12:47

    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).

  • Nach (DLL-)Funktion -> Exit

    • misterspeed
    • 9. März 2013 um 12:37

    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.

  • Nach (DLL-)Funktion -> Exit

    • misterspeed
    • 9. März 2013 um 01:00

    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.

  • Fenster im Hintergrund bedienen

    • misterspeed
    • 8. März 2013 um 21:37

    Unsinn, warum sollte controlClick das nicht erlauben, genau dafür ist es da.

    Beispiel:

    myTool.au3

    Spoiler anzeigen
    [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 ###

    [/autoit] [autoit][/autoit] [autoit]

    While 1
    $nMsg = GUIGetMsg()
    Switch $nMsg
    Case $GUI_EVENT_CLOSE
    Exit
    Case $Button1
    install()
    EndSwitch
    WEnd

    [/autoit] [autoit][/autoit] [autoit][/autoit] [autoit]

    Func install()
    run(@ScriptDir & "\setup.exe") ; vorher setup.au3 kompilieren...
    Do
    Sleep(10)
    Until WinExists("Setup Window blabla")
    WinSetState("Setup Window blabla","",@SW_HIDE)

    [/autoit] [autoit][/autoit] [autoit]

    Sleep(2000) ; nur zu demo zwecken

    [/autoit] [autoit][/autoit] [autoit]

    ControlClick("Setup Window blabla","","[CLASS:Button; INSTANCE:1]") ; 1. checkbox anhaken
    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 klicken

    [/autoit] [autoit][/autoit] [autoit]

    Sleep(2000) ; nur zu demo zwecken
    WinSetState("Setup Window blabla","",@SW_SHOW) ; sichtbar machen, siehe da alles wurde korrekt gesetzt
    EndFunc

    [/autoit]

    setup.au3

    Spoiler anzeigen
    [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 ###

    [/autoit] [autoit][/autoit] [autoit]

    While 1
    $nMsg = GUIGetMsg()
    Switch $nMsg
    Case $GUI_EVENT_CLOSE
    Exit
    case $Button1
    MsgBox(0,"setup msg","installation fertig!")
    EndSwitch

    [/autoit] [autoit][/autoit] [autoit]

    If GUICtrlRead($inputPath) <> "bitte pfad eingeben" Then
    If BitAND(GUICtrlGetState($Button1), $GUI_DISABLE) = $GUI_DISABLE Then
    GUICtrlSetState($Button1,$GUI_ENABLE)
    GUICtrlSetState($Label1,$GUI_SHOW)
    EndIf
    EndIf

    [/autoit] [autoit][/autoit] [autoit][/autoit] [autoit]

    WEnd

    [/autoit] [autoit][/autoit] [autoit][/autoit]
  • Shell Excute Geht nicht

    • misterspeed
    • 7. März 2013 um 17:33

    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.htm

    wichtig wäre z.B. das hier am Anfang deines Scriptes:

    [autoit]


    Opt("GUIOnEventMode", 1)

    [/autoit]
  • Programm versteckt starten (hidden)

    • misterspeed
    • 5. März 2013 um 18:28

    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. überschreiben

    Beide 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.

  • Programm versteckt starten (hidden)

    • misterspeed
    • 5. März 2013 um 18:12

    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.

  • ISN AutoIt Studio

    • misterspeed
    • 5. März 2013 um 15:18

    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.


    pandel:

    Danke für den Tipp, kannte ich noch nicht. Schau ich mir bei Gelegenheit mal an.

  • Programm/Script starten bei gesperrter Arbeitsstation

    • misterspeed
    • 5. März 2013 um 14:56

    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.

  • MyPic - Bilder Upload

    • misterspeed
    • 4. März 2013 um 16:55
    Zitat von Stevenx

    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?

  • [C“ 2013] The winners!

    • misterspeed
    • 3. März 2013 um 17:56

    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.

    Dateien

    wambo.png 93,9 kB – 0 Downloads
  • [C“ 2013] The winners!

    • misterspeed
    • 3. März 2013 um 17:21

    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. ;)

  • non-Array error beim _Imagesearch()

    • misterspeed
    • 2. März 2013 um 21:15

    Also sofern ich die derzeit aktuelle und richtige imagesearch.au3 gefunden habe wundert mich das nicht. Hier der problematische Abschnitt der UDF:

    [autoit]


    $result = DllCall("ImageSearchDLL.dll","str","ImageSearch","int",$x1,"int",$y1,"int",$right,"int",$bottom,"str",$findImage)

    [/autoit][autoit][/autoit][autoit]

    ; If error exit
    if $result[0]="0" then return 0

    [/autoit]

    So 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.

  • refresh #include möglich ?

    • misterspeed
    • 2. März 2013 um 12:50

    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.

  • refresh #include möglich ?

    • misterspeed
    • 2. März 2013 um 12:33

    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.

  • ISN AutoIt Studio

    • misterspeed
    • 1. März 2013 um 20:50

    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.

Spenden

Jeder Euro hilft uns, Euch zu helfen.

Download

AutoIt Tutorial
AutoIt Buch
Onlinehilfe
AutoIt Entwickler
  1. Datenschutzerklärung
  2. Impressum
  3. Shoutbox-Archiv
Community-Software: WoltLab Suite™