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

  • _IELinkClickByText Fehlerabfrage

    • misterspeed
    • 8. Dezember 2016 um 18:08

    Anmerkungen zu deiner Lösung:

    1. Das Makro @Error bezieht sich immer auf die zuletzt ausgeführte Funktion, deine zweite @Error Abfrage bezieht sich also nicht mehr zwingend auf den Link klick, sondern könnte sich bei Erfolg des Link klicks auf die Funktion Call beziehen. Deine Fehlerabfrage ist in dieser Form also suboptimal. Dafür wurde der ELSE Zweig einer IF...THEN...ELSE Verzweigung erfunden.

    2. Wie dir schon im anderen Thread erklärt wurde ist die Funktion Call überflüssig wenn du die Funktion auch direkt aufrufen kannst. Diese Funktion macht bestenfalls Sinn um komplexe Funktionsaufrufe über ein Parameterarray Zeichenmässig zu verkürzen (siehe Beispiel in der Hilfe), ein anderer Anwendungszweck wäre z.B. eine Debugfunktion die dir als Anwender erlaubt jede beliebige Programmfunktion zur Laufzeit manuell aufzurufen.

    3. In der Hilfe wird normalerweise für jede Funktion erwähnt wie sie sich im Fehlerfall oder Erfolgsfall verhält. In deinem Fall liefert die Funktion nicht nur einen Fehlercode, sondern auch einen Returnwert. Grundsätzlich würde ich hier daher auf den Returnwert prüfen um zu sehen ob es sich um einen Erfolg oder Fehler handelt und im Fehlerfall würde ich den Error Code nutzen um herauszufinden was genau das Problem war. In der Hilfe zur genannten Funktion sind immerhin 8 verschiedene Fehlerfälle dokumentiert. Ob du die dann noch detailiert abhandeln möchtest oder einfach nur den Fehlercode für Debugmeldungen verwendest bleibt dir überlassen. Im Beispiel unten wird der Fehlercode lediglich erwähnt und kann dann von dir in der Hilfe nachgeschlagen werden.

    AutoIt
    #include <IE.au3>
    
    
    Local $oIE = _IE_Example("basic")
    If _IELinkClickByText($oIE, "Link Existiert nicht") = 0 Then
       MsgBox(0,"Fehler", "_IELinkClickByText() war nicht erfolgreich. Fehlercode: " & @Error)
    Else
       hotkeyPressed()
    EndIf
  • Formular auf Webseite Automatisch ausfüllen. ... Hilfe

    • misterspeed
    • 8. Dezember 2016 um 05:44
    Zitat von Muecke

    kann man das Feld auch so verändern das es mit drin steht was ausgewählt wurde?

    Keine Ahnung. Ist aber eigentlich nicht nötig. Normalerweise sendest du das Formular ohnehin automatisiert ab und hast garkeine Zeit die Auswahl oder andere Inhalte zu sehen. Wenn du vor dem Absenden verifizieren möchtest, dass alles wie gewünscht gesetzt wurde kannst du dies mit _IEFormElementGetValue() prüfen.

    Die Funktion _IEFormElementOptionSelect() wäre diesbezüglich aber vielleicht noch ein Versuch wert.

  • Formular auf Webseite Automatisch ausfüllen. ... Hilfe

    • misterspeed
    • 7. Dezember 2016 um 22:54

    Nicht so voreillig. Nur weil du nichts von der Auswahl siehst bedeutet das nicht, dass der Wert nicht korrekt gesetzt wurde. Teste was passiert wenn du das Formular abschickst. (Form submit Button)

  • _FF Hilfe bzgl. Gmx.net

    • misterspeed
    • 7. Dezember 2016 um 22:03

    Da gibts nicht viel zu lesen. Für POP oder IMAP findest du fertige Autoit UDF's, Alternativ wäre auch die Automatisierung von Outlook oder Thunderbird denkbar (gibts ebenfalls fertige UDF's). Das simple Auslesen von Emails sollte mit allen Varianten jedenfalls kein Problem darstellen. Die darin gefundenen Links kannst du dann immernoch mit FF oder dem IE öffnen lassen, aber auch das sollte normalerweise nicht notwendig sein. (Stichworte: inetget, inetread, winhttp)

    Könnte ich dir auch mit FF helfen? Vermutlich schon, auch wenn es schon sehr lange her ist als ich für sowas noch die ff.au3 verwendet habe.
    Werd ich dir mit FF helfen? Nein, weil es meiner Meinung nach Zeitverschwendung ist.

    PS: Neben der GMX Webseite wird im Übrigen auch FF ständig geändert, solange du also nicht wie ich es damals gemacht habe eine fixe "veraltete" FF Portable Version nutzt musst du auf Dauer auch hier mit diversen Problemen rechnen und ständig MozRepl und ggf. die FF.au3 aktualisieren / selbst anpassen.

  • _FF Hilfe bzgl. Gmx.net

    • misterspeed
    • 7. Dezember 2016 um 21:32
    Zitat von XxJusoxX

    Das ganze muss mit _FF Funktionieren. Bitte keine Varianten Mit POP3 oder IMAP. Danke..

    Ähm und warum?

    Es macht keinen Sinn einen webmail Dienst zu automatisieren wenn genausogut auch POP / IMAP nutzbar wäre.

    Letzteres ist eindeutig vorzuziehen, alleine schon deshalb weil sich das POP / IMAP Protokoll nicht mehr nennenswert ändern und bestenfalls um Kleinigkeiten ergänzt werden wird. Der Webmail Auftritt von gmx wird hingegen mit Sicherheit regelmässig einem Face Lift unterzogen und ggf. in der Zukunft neue Webtechnologien nutzen, was wiederum erhebliche Anpassungen in deinem Script erfordern könnte. Selbst die kleinste Designänderung kann dein Script unbrauchbar machen.

    Davon ab ist POP oder IMAP um ein vielfaches performanter als eine Browserautomatisierung.

  • Formular auf Webseite Automatisch ausfüllen. ... Hilfe

    • misterspeed
    • 7. Dezember 2016 um 20:26

    Achja ich würde mir an deiner Stelle außerdem mal die winhttp.au3 anschauen anstatt den IE oder FF zu automatisieren. Direkte HTTP Posts versenden ist um ein vielfaches performanter.

  • Formular auf Webseite Automatisch ausfüllen. ... Hilfe

    • misterspeed
    • 7. Dezember 2016 um 20:24

    Naja ist doch klar warum das so nix wird. Du willst das Form Element mit der Auswahlliste manipulieren. Dieses Formelement ist eindeutig bezeichnet (name="brandno" und id="wearpartsManufacturer"), es bleibt dir überlassen ob du id oder name verwendest um das Element zu ermitteln.

    Deine Elementsuche liefert dir aber das Input Feld mit der Bezeichnung name="searchGenericArticleNumber".

    Desweiteren kannst du als Wert für eine Auswahlliste wie hier keinen Text setzen, sondern du musst stattdessen die value id verwenden.

    Vorgehensweise also:

    1. Form Objekt ermitteln
    2. Element Objekt ermitteln
    3. Einen erlaubten Wert für das Element Objekt setzen (hier nur Zahlen)

  • Hilfe zu IniRead

    • misterspeed
    • 6. Dezember 2016 um 09:21

    Vielleicht hast du dich ja auch nur falsch ausgedrückt, aber ich denke du solltest dir auch iniread nochmals in der Hilfe anschauen. Dein 4. Funktionsparameter $SN macht jedenfalls keinen Sinn. Der 4. Parameter ist zur Angabe eines Default-Wertes vorgesehen für den Fall, dass die Sektion oder der Schlüssel nicht existiert und iniread scheitert. Die ID eines Controls hat hier jedenfalls nichts verloren.

    Wie dem auch sei... wenn du eine unbestimmte Anzahl an Sektionen hast brauchst du wie schon erwähnt wurde inireadsectionnames. Das Array enthält dann alle vorhandenen Sektionen. In einer Schleife könntest du dann für jede gefundene Sektion ein inireadsection durchführen um alle in der Sektion enthaltenen Schlüssel-Wert Paare zu ermitteln, alternativ nur ein iniread für fix definierte Schlüssel die dich interessieren.

    Durch Nutzung beider "section"-Funktionen bist du 100% dynamisch und es spielt keine Rolle wieviele Sektionen oder Schlüssel es gibt. Die Schwierigkeit besteht allerdings die INI dann noch dynamisch in der GUI zu visualisieren, denn eine GUI hat oftmals fixe Grenzen und kann nicht beliebig viele Daten darstellen. Daher solltest du geeignete Controls verwenden, welche über Scrollbars verfügen. Ein Inputfeld kann jedenfalls immer nur einen Wert darstellen (außer du zeigst einen verketteten String an, was aber meist keinen Sinn macht).

    Eine typische vorgehensweise in einem Fall wie deinem wäre die Servernamen von inireadsectionnames in einer Auswahlliste (combobox oder listbox) und die Eigenschaften des jeweils ausgewählten Servers in dafür vorgesehenen Inputfeldern, Checkboxen, Radioboxen usw. anzuzeigen.

    Um Arrays kommt man da mit Sicherheit nicht herum. Programmieren ohne Arraynutzung ist wie Fahrradfahren mit Stützrädern.
    Lies dich einfach mal ins Arraytutorial von Bugfix ein: http://www.bug-fix.info/array_tut.htm

  • Nicht Gebrauchten Browser schließen

    • misterspeed
    • 30. November 2016 um 18:25

    Stattdessen sollte man wohl eher die komplette Anmeldesitzung nach x Minuten Inaktivität "sperren" oder Abmelden lassen. Das kann problemlos per Gruppenrichtlinie oder Registry fest für den Rechner eingestellt werden, da brauchts dann nichtmal ein permanent laufendes Autoitscript dafür. Je nach Rahmenbedingungen kann das durchaus Sinn machen und unbedarfte Anwender vor sich selbst schützen (z.B. öffentlicher Computer, der von beliebigen Personen genutzt wird).

  • Spielzeiten von Video-Dateien auslesen

    • misterspeed
    • 28. November 2016 um 21:34

    :P

    Jupp da hast du durchaus recht. Meine ersten Versuche waren damals auch noch mit der EXE Variante. Aber das erwähnte Beispielscript liefert einem eigentlich fast alles was man braucht. Mehr Arbeit ist es letzlich auch nicht, zumindestens dann wenn man die Daten noch weiterverarbeiten muss. Wie dem auch sei, ich denke er hat genug input um seine Aufgabe zu bewältigen. Wie ist letztlich ja egal. ;)

  • Wo läuft was????

    • misterspeed
    • 28. November 2016 um 19:45
    Zitat von Peter S. Taler

    misterspeed.
    Sorry, aber Server und locales Laufwerk wurden in meinem Post klar def.

    Nein hast du eben nicht.

    Server ist ein viel zu allgemeiner Begriff.

    Dein Server könnte sein:
    - Windows Dateiserver, welcher deine Autoit Scripte ausschließlich per SMB Freigabe bereitstellt
    - Windows Terminalserver, welcher theoretisch in der Lage wäre via Remoteanmeldung oder Remoteausführung das Script direkt auf dem Server auszuführen
    - Dein Autoit Script selbst könnte ein TCP Server sein oder eben nur lokal auf dem ausführenden Rechner Dinge tun und wäre somit keine Serveranwendung
    - Ja sogar ein Samba Server auf Linux Basis könnte hier als Dateiserver fungieren, in dem Fall ist eine Autoit Ausführung direkt auf dem Server natürlich ausgeschlossen

    Dein letzter Beitrag macht dies immernoch nicht klar. Er verwirrt nun noch mehr durch diese Sätze:

    Zitat

    Besonders Programmaufrufe von "hilfsoutinen" via runwait machen Sorgen

    Welche Programmaufrufe? Welche Hilfsroutinen? Windowseigene Hilfsprogramme? Wo sollen/müssen diese ausgeführt werden? Auf dem Client oder auf dem Server?

    Zitat

    Was passiert wenn man eine Autoit exe via Timer auf einem Server ohne Anmeldung laufen läßt?


    Welche Timer? Autoit Timer? Windows Aufgabenplanung?
    Server ohne Anmeldung? Redest du nun von einer Windows Server Core Installation? Redest du von einem Dateiserver auf dem du keinen Remotezugang hast, weil du oder der ausführende User hierfür nicht berechtigt ist?

    Als Administrator habe ich wirklich Kopfschmerzen wenn ich mir diese Beschreibung durchlese. Achja was heißt überhaupt "deutlich langsamer"? Sekunden, Minuten, Stunden?
    Außerdem vielleicht noch relevant... wie wird die Netzwerkverbindung realisiert? LAN? WLAN?

    Meinen Hinweis bzgl. Virenscanner hast du im Übrigen ignoriert. Nicht nur Virenscanner, sondern auch die Windows Benutzerkontensteuerung reagieren bei Ausführung von Software über Netzlaufwerke stärker als üblich.
    Testweise würde ich den Virenscanner auf dem Clientrechner daher deaktivieren und prüfen ob sich die Performanceprobleme dadurch ändern. Falls ja kann das Verzeichnis evtl. als Ausnahme definiert werden.

    Aber ich hör nun auf mit meinen Fragen. Bei solchen Problemen muss man aber meiner Meinung nach eben sehr viel klarer und deutlicher die Rahmenbedingungen beschreiben.

  • Spielzeiten von Video-Dateien auslesen

    • misterspeed
    • 28. November 2016 um 18:05

    Filesharer? :D

    Da ich selbst mal sehr aktiv in diesem Bereich war wäre auch mein Tipp mediainfo zum Ermitteln der Videodatei Eigenschaften zu verwenden.

    Ich verwende in meinen Programmen hierfür aber nicht die mediainfo.exe mit Dateioutput, sondern ich verwende die mediainfo DLL. Das schöne ist, dass das Mediainfo source Paket sogar mit einem Autoit Beispielscript geliefert wird, welches die Nutzung der DLL beispielhaft zeigt. Vorteil von der DLL Methode ist, dass man die Werte sehr viel schneller zur Verfügung hat und nicht erst wieder aus einem Textoutput parsen muss. Ich benötige die Einzelwerte z.B. nicht nur zur Erzeugung einer NFO-Datei, sondern auch für diverse Entscheidungen im weiteren Programmablauf.

    https://mediaarea.net/de/MediaInfo/Download/Windows

    32bit Source: https://mediaarea.net/download/binar…outInstaller.7z

    Das Autoit Beispiel liegt im Unterordner "\Developers\Source\Example"

  • Wo läuft was????

    • misterspeed
    • 28. November 2016 um 06:43

    Da du nicht besonders eindeutig bist wenn es um die Problembeschreibung geht...

    Ich nehme an, dass:

    - S:\ ein verbundenes Netzlaufwerk auf einem Dateiserver ist
    - L:\ ist eine lokale Festplatte oder ebenfalls ein Netzlaufwerk?

    Wie dem auch sei... du schreibst, dass es gerademal 100 Dateien mit einer Gesamtgröße von unter 4 Megabyte sind. Da sollt ein Kopiervorgang selbst über ein Netzlaufwerk noch schnell arbeiten.

    Wie ist der Server angebunden? Reden wir hier von einem lokalen Netzwerk mit mindestens 100mbit oder reden wir hier von einer Internetanbindung zwischen zwei Standorten via VPN? Bei letzterem ist es natürlich stark davon abhängig über wieviel Up/Download Client und Server Standort verfügt. Hier kann die Übertragung von ca. 4mb dann durchaus etwas länger dauern.

    Weitere Bremsen können Virenscanner sein, welche beim Nachladen von Daten via Netzlaufwerk genauer hinschauen.

    Grundsätzlich denke ich auch, dass ein Kopieren von S:\ nach S:\ nur dann schneller geht wenn es sich nicht um Netzlaufwerke handelt, also der Kopiervorgang wirklich lokal auf dem Server abläuft. Bei einem Netzlaufwerk werden die Daten denke ich zuerst in den Speicher des lokalen Rechners kopiert und von dort wieder zum Netzlaufwerk hochgeladen. Ein lokales Kopierscript wäre z.B. wenn auf dem Server ein Script laufen würde, welches von deinem Anwenderscript Comandos entgegennimmt und diese dann lokal auf dem Server ausführt. Alles was ein Anwender vom Netzlaufwerk startet läuft nicht auf dem Server, sondern auf dem Client (die exe wird auf der lokalen CPU und auf dem lokalen Betriebssystem auseführt). Das Netzlaufwerk stellt nur die Daten der ausführbaren Datei bereit.

  • Verknüpfung oder Script

    • misterspeed
    • 26. November 2016 um 20:00

    Unsinn. Was von Hand lauffähig ist muss auch via Scite lauffähig sein. Bei der Nutzung von DLLs ist es hingegen wichtig, dass der korrekte zur DLL passende Autoit Interpreter genutzt wird (ein 32bit Interpreter kann nichts mit 64bit dlls Anfangen). Deswegen mein Hinweis zu #AutoIt3Wrapper_UseX64

    Aber ist ja letztlich dein Problem. ;)

  • Verknüpfung oder Script

    • misterspeed
    • 26. November 2016 um 19:22

    Der Aufruf aus dem Editor ist identisch zum Aufruf mit dem Autoit Interpreter, denn Scite macht nichts anderes als das was du in deiner Windowsverknüpfung auch machst. Es ruft die vorhandene Autoit.exe mit AU3 als Parameter auf. Allerdings führt Scite bevor es das Script zur Ausführung bringt noch eine Syntaxprüfung deines Scriptes durch und bricht ggf. ab wenn dein Script Fehler enthält. Außerdem kann es sein, dass Scite standardmässig die 32bit Version des Interpreters nutzt. Das kannst du aber ändern bzw. erzwingen indem du am Scriptanfang definierst wie das Script zu interpretieren/auszuführen bzw. zu kompilieren ist.

    AutoIt
    #AutoIt3Wrapper_UseX64=y
    MsgBox(0,"x64?",@AutoItX64) ; sollte immer 1 ergeben
    oder:
    #AutoIt3Wrapper_UseX64=n
    MsgBox(0,"x64?",@AutoItX64) ; sollte immer 0 ergeben


    Und ja mit $cmdlineraw kannst du das bedingt erkennen, aber nur dann wenn bei dir alles dem Standard entspricht und du ausschließen kannst, dass bei manuellem Interpreteraufruf der Parameter "/ErrorStdOut" an den Interpreter übergeben wird. Zumindestens meine Scite Version tut dies standardmässig und unterscheidet sich dadurch evtl. von manuellen aufrufen via Interpreter.

    An deiner Stelle würde ich aber mal Details zum Fehler bei Scite Ausführung nennen. Dein Problem oder Fehler lässt sich mit Sicherheit lösen.
    Wie willst du dein Programm vernünftig entwickeln und testen wenn es schon bei der Ausführung via Scite zu Fehlern kommt?

  • AutoIt-Script-Zeilennummern anzeigen in kompillierten exe Dateien

    • misterspeed
    • 26. November 2016 um 18:34
    Zitat von autoiter

    Hallo @hevilp,

    *hust* war genau mein Gedanke...

  • Verknüpfung oder Script

    • misterspeed
    • 26. November 2016 um 18:25

    Verstehe den Sinn deiner Frage nicht so wirklich.

    @compiled genügt um festzustellen ob das Script kompiliert wurde oder als au3 vorliegt und durch eine vorhandene Autoit Installation oder ggf. durch ein anderes kompiliertes Script interpretiert wird.

    Was willst du mehr wissen und vorallem wozu? Welchen Unterschied soll es machen ob ich eine Windows Verknüpfung zum Start verwende oder die Datei direkt im Explorer oder per CMD Fenster aufrufe?
    Da gibts einfach keinen Unterschied. Im Falle einer AU3 Datei wird immer ein Interpreter benötigt (autoit.exe) und im Falle einer EXE Datei wird Windows die Datei direkt mit Bordmitteln zur Ausführung bringen.

    $CMDline[0] ist null weil du eben keine Parameter an das Script übergibst, sondern nur einen Parameter an den Interpreter (Autoit.exe).

    Parameter an das Script kannst du aber auch bei der Nutzung eines Interpreters durchreichen:

    Code
    ; Interpreter-Aufruf mit 2 Parametern
    "C:\Program Files (x86)\AutoIt3\AutoIt3.exe" "C:\Program Files (x86)\AutoIt3\test.au3" -testtext -test2
    
    
    ; EXE Aufruf mit 2 Parametern:
    "C:\Program Files (x86)\AutoIt3\test.exe" -testtext -test2


    Beides liefert dir für $cmdline[0] eine 2. Du kannst also keinen Unterschied zwischen kompilierter Fassung oder interpretierter AU3 Fassung feststellen. Durchaus einen Unterschied siehst du aber wenn du dir $cmdlineraw ausgeben lässt. Hier siehst du bei der nicht kompilierten Fassung zusätzlich noch den Parameter mit dem Pfad zur au3-Datei.

    Sinn der Frage ist trotzdem nicht klar... @compiled reicht völlig um den Unterschied zu erkennen. $cmdline**** wird dir auch nicht sagen können wie der Benutzer das Script letztlich gestartet hat. Eine Windowsverknüpfung ist genau das selbe wie ein cmd Aufruf oder ein start im Explorer oder in Scite. Bei allen Varianten wird die Autoit.exe mit dem Scriptpfad als Parameter gestartet.

  • Besitzt die For-In-Schleife nativ eine Indexvariable analog wie bei For-To?

    • misterspeed
    • 26. November 2016 um 14:42

    Kleiner Tipp am Rande:

    Mit dieser besserwissenden und kleinkarierten Art wirst du hier nicht allzulange ernst genommen werden. Wenn du ernsthaftes Interesse an Autoit und an Problemlösungen hast würde ich dir ein anderes Auftreten nahelegen. Nicht wir wollen etwas von dir, sondern du brauchst uns um deine Fragen zu beantworten oder Probleme zu lösen. Wenn du uns auf den Zeiger gehst bekommst du eben keine Hife mehr, das haben andere schon vor dir lernen dürfen. Das ist im realen Leben im Übrigen auch nicht anderst. Du kennst sicher das Sprichwort "Wie es in den Wald hineinruft..."

    Für die Zukunft kannst du vielleicht folgendes aus diesem Thread mitnehmen:

    1. Bevor man fragen stellt liest man sich erstmal in das Thema ein. z.B. Autoithilfe oder externe Tutorials zum Thema Arrays und Schleifen
    2. Wenn man nicht fündig wird oder nachwievor Verständnisprobleme bestehen überlgt man sich was eigentlich das Problem und vorallem was das Ziel ist, denn der Weg zum Ziel ist variabel, Probleme müssen nicht zwangsläufig gelöst werden wenn man sie auch durch Alternativen umgehen kann.
    3. Anschließend versucht man das so gut wie möglich zu beschreiben und konkretre Fragen zu stellen. Bevorzugt mit lauffähigen Beispielscripten die deine bisherigen (Fehl-)Versuche zeigen. Damit zeigst du, dass du bereits Eigeninitiative ergriffen hast.
    4. Unabhängig von der Qualität der Antworten legt man weder aggressives, abwertendes oder verletzendes Verhalten an den Tag... man bleibt stattdessen freundlich, geduldig und lösungsorientiert. Das ist im realen Leben genauso... solange ich etwas von jemandem brauche denk ich mir eben meinen Teil und sage ihm nicht ins Gesicht, dass er ein Vollidiot ist.
    5. Es schadet im Übrigen nicht auch mal ein wenig über den Tellerand hinauszuschauen und sich seine Gedanken zu machen ob der andere vielleicht ja doch Recht hat und garnicht so daneben liegt mit dem was er sagt oder schreibt.
    6. Nach Lösung des Problems markiert man den Thread durch Editieren des 1. Postings als "gelöst" und bedankt sich bevorzugt für die Hilfe.

  • Besitzt die For-In-Schleife nativ eine Indexvariable analog wie bei For-To?

    • misterspeed
    • 26. November 2016 um 11:40

    Lesen hilft... verwende einfach eine eigene Zählervariable in der Schleife wenn du unbedingt eine FOR...IN Schleife verwenden willst.... warum auch immer...
    Vermutlich hast du dir auch das Array Tutorial von Bugfix noch nicht angesehn und keine Ahnung wofür man ubound() nutzen könnte wenn man dann doch lieber zur FOR...TO Schleife wechselt.

  • Besitzt die For-In-Schleife nativ eine Indexvariable analog wie bei For-To?

    • misterspeed
    • 26. November 2016 um 10:50

    Es hindert dich niemand daran eine eigene Zählervariable in der Schleife zu erhöhen um letztlich rauszufinden wo du dich aktuell befindest.
    Dann kannst du aber auch einfach gleich einen FOR...TO Schleife nutzen.

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™