Ich würde mir wünschen, dass man einen Datentyp beim deklarieren vorgeben kann. Wenn keiner angegeben ist, dann halt Variant.
So könnte man die Vorteile nutzen und müsste sich nicht mit den Schwierigkeiten des Variant in manchen Situationen rumschlagen.
Wie in Basic:
Foo as Long
Bar as Variant- Zählervariablen, die auch außerhalb der Schleife weiter existieren
Das ist doch normal.
Da hat er Recht.
Zitat von BugFixDatentyp Variant ( Ich weiß, dass vielen dieser Datentyp gefällt, aus meiner Sicht fördert er nur eine schlampige Programmierweise. )
Zumal Variant in AutoIt nicht konsequent durchgesetzt ist.
[Blockierte Grafik: http://www.zentrale-treff.de/images/feiern/schnitzel.jpg]
Alles Gute 
womit ihr hauptsächlich arbeitet
Nicht mit AutoIt 
. Spaß Beiseite: Ist ja noch ganz nützlich. Solange man keine Spielreien wie Bitmap-Handling macht oder auf PlugIns angewiesen ist, kann man natürlich auf .10.2 umsteigen.
Du solltest vielleicht mehrere Möglichkeiten zulassen
3.3.8.1 für Release-Projekte
3.3.9.5.X2 für kranke Experimente (aufgepusht mit allen Präprozessoren und PlugIns die sich im Laufe der Zeit angesammelt haben.)
3.3.10.2 ausschließlich zum Testen, was verändert werden muss, damit Projekte auch von .10.2 Nutzern ausgeführt werden können.
// Muss mal das Archiv updaten
Alles Gute & gute Besserung 
Lässt sich noch machen, kein Problem. Braucht bloß seine Zeit.
Das passiert wenn die Threads nicht richtig synchronisiert werden. Es liegt nicht am Code, allerdings lässt sich da auch ein Workaround bauen, daran arbeite ich. . Was das Programm anzeigt ist eigentlich irrelevant, auch wenn sich nichts bewegt, arbeitet es noch.
Moin.
Hier mal ein kleines Tool für den Stabilitätstest von der CPU (z.B: nach OC). Einfach die eurer CPU entsprechende Datei ausführen, beendet werden kann jeder Zeit.
Warnung: Einen höheren Core-Count als den physikalischen zu wählen verfälscht die Ergebnisse und führt zu Instabilität.
Viel Spaß
Dazu musst du das Fenster mit dem Style $WS_EX_TOOLWINDOW erstellen.
Obfuscaten bringt dir wenig. Es verändert nur den Code. Hat der h4xx0r eine AutoIt Executable und einen Decompiler, dann hat er das Skript. Ob es nun aufgrund des Obfuscators "hässlich" aussieht macht keinen Unterschied: Er hat das Skript. Dann kann er systematisch Funktionen außer Kraft setzen und so weiter ... ich glaube du verstehst das Problem
Wenn schon, dann mit Call() und nicht mit Execute.
Alles gute
Du musst die Werte der Controls mit GuiCtrlRead() auslesen.
Also lieber mit Pixelpattern statt ImageSearch arbeiten.
Oder, oder, oder einfach mal die nativen AutoIt Funktionen für Fenster nutzen. Wäre ja nur so eine Idee 
. PixelSearch ist so ziemlich das abwegigste hier.
Willkommen
Ja Andy, Funky hat es richtig erkannt. Nur woher weiß er das? Meine IP? Nee, ich bin ja via Fernwartung auf meinen PC zuhause hier online.
Oder wird doch die IP von hier genommen? Finde es aber gut, das die Steckdose und alles via Telefon zu steuern ist. Sonst hätte ich ja auch
keinen Zugriff auf meine Script und Co.
Du holst mich jetzt nach, Ticket bezahlst du, dafür helf ich dir auch bei jedem AutoIt Problem 
Nein, im Ernst: Viel Spaß
Hier findest du ausreichend große Dateien, die für Speedtests gedacht sind: http://www.speedtest.qsc.de/
Ob du erst die GUI erstellst oder erst die sachen lädst, es wirkt vielleicht anders auf dich da du schon die GUI siehst, aber durch das tauschen der Codeschnipsel wirst du es nicht "schneller" öffnen
Wäre wohl schlauer, dieses nur zu laden wenn sie auch gebraucht werden.
Dass Probiere ich mal aus.
Hat vll. jemand eine Idee wie man den Code allgemein kürzen bzw. vereinfachen kann?
Was hat die Länge des Codes mit der Ladezeit zu tun? Warum der Start so lange dauert, liegt an den Inet...() Befehlen, die alle Größen laden; erst danach wird die GUI überhaupt initialisiert.
