Beiträge von Andy

Also nochmal ganz langsam....

Zitat

Und ja, die Verbindung kann nur an einer Stelle hergestellt werden, genau daher möchte ich ja, dass wenn in einer anderen Funktion die Verbindung nicht mehr da ist (es also z.B. Arrayfehler deswegen gibt), dass man wieder zum Anfang der Schleife kommt, wo die Verbindung geprüft und evtl. erneut hergestellt wir

Wer hindert dich denn daran, im Fehlerfall "an den Anfang der Schleife" zu springen?
Ich bin BugFixens Meinung, dass dein Programm strukturell garnicht in der Lage ist "Fehler" überhaupt abzufangen!
Gesetzt den Fall, die Datenverbindung besteht nicht (oder reisst ab), dann MUSS dieser Fall doch programmiermäßig abgefangen werden!
Ob du das jetzt mit einem Errorhandler machst, oder mit einer Abfrage "zu Fuß" ist hierbei völlig irrelevant.
Programmstruktur simpel:

Wenn Fehler bei der Datenverbindung, dann
   - Userinteraktion (Datenverbindung neu starten etc.)
ansonsten
   -Script fortführen

Wenn dein Script diese Struktur nicht hergibt, dann ist das ein Konstruktionsfehler, aber völlig unabhängig vom "Errorhandling"!

Zitat

Hat denn jemand nun ne Lösung für mein Problem / eine Antwort auf meine Frage?

lies meinen Post nochmal, und den darauffolgenden von Bugfix, dann solltest du wissen, wie man diese "Fehler" abfängt!
Ein "sauberes" zurückkehren in dein Programm ist doch sowieso nicht möglich, also solltest du im "Fehlerfall" genug informationen bereitstellen, um diese in einer MsgBox darzustellen.
So mache ich das jedenfalls:

OnAutoItExitRegister("Error")

Global $modulname = "Testscript"
Global $funktionsname
Global $Fehlertext

loop()

Func loop()
$funktionsname = "Loop"
Dim $a[10]
For $i = 1 To 42
$Fehlertext = "Schleifenvariable $i=" & $i
$a[$i] = "pft" ;hier kommt der Fehler
Next
EndFunc ;==>loop

Func Error()
MsgBox(0, "Fehler aufgetreten", "Fehler im Modul " & $modulname & @CRLF & "Funktion " & $funktionsname & @CRLF & @CRLF & $Fehlertext)
EndFunc ;==>Error

Hi,
ja, Sleeps sind Gold wert!
Btw. eine fehlerhafte Ausführung bei einer Zeile wie

Send("{ALT}{RIGHT}{RIGHT}{RIGHT}{RIGHT}{RIGHT}{RIGHT}{RIGHT}{RIGHT}{RIGHT}{ENTER}{DOWN}{DOWN}{DOWN}{DOWN}{DOWN}{DOWN}{ENTER}")

ist vorprogrammiert!
Wie soll man das jemals debuggen?

Send ist immer gut und schön, solange das Control an das etwas gesendet wird, die Sendung auch annimmt!
Dazu muss das Control empfangsbereit sein.
Ich habe aktuell eine spezialisierte Firmensoftware zu automatisieren, bei der empfangen einige Controls die Msg erst 500ms, nachdem sie sichtbar sind!
Fenster sichtbar, Control sichtbar, aber Controlsend funktioniert erst eine halbe Sekunde später.....

Hi,
wenn du jetzt noch schreibst, dass die Lösung deines Problems darin lag, dass DllCall() ein Array zurückgibt, kannst du den Thread auf gelöst setzen

In letzter Konsequenz führt das dazu, dass man eine BitMap Pixel für Pixel animiert

Hi,

Zitat

..Überleg mal, wieviel Zeit und Energie du inzwischen aufgewendet hast, um dich vorm Error-Handling zu drücken.
In der Zeit hättest du auch locker das Errorhandling geschrieben.

Sehe ich garnicht so.
Fehler können nur dann abgefangen werden, wenn bekannt ist wo sie überhaupt entstehen können!
Ich kann 80% meines Codes mit Errorhandling verbraten und trotzdem einen "Fehler" produzieren!

Ein "einfach so" abstürzendes Programm ist so ziemlich die armseligste Leistung, die ein Programmierer abliefern kann!
Und die "typischen" Fehlermeldungen von AutoIt gehören da VOLL dazu!

Ich selbst versuche im Produktivumfeld Fehlermeldungen zu verfassen, die dem User die Möglichkeit geben, mir als dem Programmierer GENAU zu beschreiben, wo, wann und warum ein Fehler aufgetreten ist.
Und das hat alles nichts mit dem "vorbeugenden Errorhandling" zu tun!
Es ist ohne weiteres möglich, im Fehlerfall eine Meldung zu generieren im Stile von:
"Fehler im Modul _Tralala() in der Funktion _blablub().
Folgende Daten bitte an xyz weitergeben:
....
....(siehe Beispiel COM-Error)
"

Solch eine Fehlermeldung ist produktiv und ich kann SOFORT lokalisieren, wo und ggf. warum ein Fehler aufgetreten ist.
Die 08/15 AutoIt-Fehlermeldung "Crash an 0xABC0123E in Zeile 0" ist derart ARMSELIG, es wäre besser, das Programm würde kommentarlos seinen Dienst beeenden!
Aber das kommt davon, wenn man großkotzig über die "BASIC"-Fuzzis lacht, welche schon im ersten IBM-XT von 1983 im ROM einen Basic-Interpreter hatten, welcher eine OnErrorGoto()-Funktion beinhaltete....

Zitat

da ich mit dem Gedanken spiele mir einen Text auf die Art tattoowieren zu lassen

"Penny, wieso hast du dir das chinesische Schriftzeichen für "Suppe" rechts auf den Hintern tätowieren lassen?"
"Aber Sheldon, das heisst nicht Suppe sondern Tapferkeit! "
"Nein, heisst es nicht! Aber man muss wohl sehr tapfer sein, um seine Begeisterung für Suppe auf diese Weise zu demonstrieren!"

Hi,

Zitat

AutoIt hat doch einen Debugger, also für mich ist die console schon debug genug,

wenn du mit den AutoIt-internen Debug-Möglichkeiten zurecht kommst, dann reicht das imho auch völlig!

Einen "echten" Debugger braucht man dann, wenn man tief in die Eingeweide des Source-codes und in die davon aufgerufenen Funktionen eintauchen MUSS! Muss deshalb, weil es in anderen Sprachen Möglichkeiten der fehlerhaften Programmierung gibt, die bei AutoIt "so einfach" garnicht vorkommen können. Ausnahme sind extern aufgerufene Funktionen bspw. dll-calls, aber für den 08/15-Programmierer ist es auch da egal wo in der dll der code abschmiert....ich gehe mal davon aus, dass für die dll eine Beschreibung der Funktionen und Parameter existiert und der 08/15-Programmierer sich einfach daran hält und alles klappt!
Tut es das nicht und er hat auch keine Ahnung wie und warum ein Fehler auftritt und kennt sich weiterhin auch nicht mit dem Debuggen externer Anwendungen aus, dann nützt "auf die Schnelle" auch kein Youtube-Tutorial und die Installation eines Debuggers...fehlendes KnowHow ist immer problematisch

Zitat

was meinst du mit botter und ollydbg, ok ollydbg für gamehack, ist das ein "must have"

made my day...
Einen Debugger fürs gamehack zu verwenden ist in etwa so, als ob man seinen Zeigefinger ausschliesslich fürs Nasebohren verwendet!
Dabei kann man den auch fürs Klavierspielen benutzen, fürs Malen, fürs Telefonieren, zum Arbeiten....

Zitat

Was käme denn dann für ne special Meldung raus wenn ich das habe?

Falsche Frage!
Die richtige wäre gewesen:"Wozu braucht man einen Debugger?"

Zitat

ber wie erklärst du dir den Umstand, das es manchmal klappt egal welchen datentyp ich mit welcher size auch immer verwende?

Mist gemacht und trotzdem Glück gehabt....

Bei jedem Programmstart werden Speicherbereiche reserviert+wieder freigegeben. Manchmal hat man Glück und "hintendran" ist unused Memory. Hat man kein Glück und Windows hat die Struct in irgendeinen fragmentierten Speicherbereich gequetscht, dann ist das nächste Byte "hinter" deiner Struct von einem anderen Programm oder Daten belegt und damit geschützt. Wenn du trotzdem darauf zugreifen willst, Exception wg. Speicherverletzung.
Das kannst du übrigens mit einem herkömmlichen Debugger prüfen, der statt der AutoIt-Fehlermeldung im System aktiviert wird...Die Botter haben den OllyDbg alle, der kann das auch^^

:pinch:

das "aktuelle" hat aber immer noch die Jahresangabe....daher mein dezenter Hinweis, wenn wir weitere x Monate warten, nützt uns das schönste Logo "ohne" nix

Hi,
dein Problem ist, dass du auf 260 Byte Speicher mit

$struct = DllStructCreate("WCHAR[260]", $ptr)

zugreifen willst, aber garnicht weisst, wie groß deine Struct wirklich ist....
Angenommen, die Struct hat eine Länge von 53 Bytes, und ab dem 54.Byte fängt eine (vom Speichermanagement geschützte) andere Struct an, dann bekommst du eine Zugriffsverletzung, also Absturz.

Also musst du für die Struct die GENAUE Anzahl Bytes herausfinden!
Ich mache das immer so, dass ich die entsprechenden *.h-Dateien bzw. Projekte in das VisualStudio lade und mir dann "rückwärts" die genaue Definition (Datentyp) von bspw. "DismRestartType" hole.
Dann kommt bspw. heraus, dass jeder Member in dieser Struct ein UINT ist, dann weiss ich, das sind 4 Bytes.....Summe aller Bytes sind bspw. 53.
Damit erstelle ich dann eine Struct, welche ich an die Position des Startpointers schreibe und somit mit "meiner" Struct die Daten auslesen (und prüfen!!!) kann!

Wenn man im Falle eines PCWSTR also eines Pointers auf einen string unbekannter länge nicht weiss, wie lang der string ist, dann ist

$struct = DllStructCreate("WCHAR[260]", $ptr)

suboptimal! Entweder die 260 Bytes (Unicode^^ ) sind zu groß, dann Absturz s.o., oder der angezeigte String ist in der Mitte abgeschnitten...

Also etwa so:

;wir bekommen den Pointer von einem "unbekannten" String
$struct = DllStructCreate("WCHAR[260]") ;platz für string reservieren...viel zu viel
DllStructSetData($struct, 1, "Hallo AutoIt!" & Chr(0)) ;"unbekannten" unicodestring schreiben

$ptr = DllStructGetPtr($struct) ;pointer bekommen

;ab hier gehts los
$i = $ptr ;zeichenzähler
Do ;jede speicherstelle im string durchlaufen, bis stringende
$char_struct = DllStructCreate("WCHAR", $i) ;speicherstelle auswählen
$i += 1 ;Zeichenzähler
$char = DllStructGetData($char_struct, 1) ;char an dieser Position lesen
Until $char = Chr(0) ;string ende

$stringstruct = DllStructCreate("WCHAR[" & Int($i - $ptr) & "]", $ptr);struct an stringposition mit genauer anzahl bytes erstellen
$string = DllStructGetData($stringstruct, 1)
MsgBox(262144, 'Debug line ~' & @ScriptLineNumber, 'Selection:' & @LF & '$string' & @LF & @LF & 'Return:' & @LF & $string) ;### Debug MSGBOX

Hi,

Zitat

Und mithilfe der Zeilennummern, welche der Syntax-Checker ausspuckt, solltest du deine Fehler selbst finden können.

Ein Doppelklick auf die in der Scite-Console angezeigte Zeile lässt den Cursor auf den fehlerhaften Code springen.

GtaSpider , bevor du dich auf den Glückwünschen ausruhst, mach mal besser schon die Version für 2016ff
Bald ist Weihnachten, und das 2012er Logo ist immer noch auf der Startseite

Hi,
stell mal bitte alle deine für das Script notwendigen Daten, also die aktuelle Scriptversion, Maps, Bitmaps usw. in den Startpost.
Dann kann man testen und auch ggf. den einen oder anderen Verbesserungsvorschlag, bspw. auch das korrekte Backbuffering , anbringen...

Ich würde dir ausserdem empfehlen, dir die Scripte in der Signatur von unserem Forenmitglied UEZ anzuschauen, das meiste davon hat mit Grafiken zu tun, komprimierteres KnowHow wirst du in Verbindung mit AutoIt nur schwer finden

...und falls die Frage nach Scripten aufkommt, die stehen beide in der Hilfe.
Eine "Anleitung" gibt es hier.

Hi,
in Excel erkennt man die zu filternden Spalten an Zellen, welche ein nach unten zeigendes Dreieck auf der rechten Seite haben.
Die Tabelle verändert man mit Filtern nicht, aber das, was man "sieht". Die Filter filtern die Ansicht der Daten...

Jetzt gibt es für dich 2 Möglichkeiten:
- Entweder dein Vater stellt die Filter so ein, dass man "alles" (also die gesamte Tabelle) "sieht" und speichert dann, oder
- er vergisst das AutoIt-Script, denn AutoIt kann nichts dafür, dass der Excel-Befehl für das Auflösen der Filter nicht richtig funktioniert!

Die Filter müssen nicht gelöscht werden, sondern nur auf "alles anzeigen" gestellt sein!

Hi,
das ist kein Fehler von AutoIt, sondern von Excel.

Versuche mal, sämtliche gesetzten Filter in Excel auszuschalten, speichern und dann erst mit AutoIt zu bearbeiten

Hi,
F4R, such mal zum Thema "Flackern" nach "Backbuffer" und wie und wozu dieser benutzt wird.

Dann solltest du dir überlegen, wie du diese ellenlangen, immer wiederkehrenden Passagen in deinem Script sparen kannst.
Bspw. deine Funktion _OpenMap(). Du könntest dir sämtliche IF-Abfragen bis auf eine sparen, wenn du die x- und y-Koordinate bspw direkt in den Namen integrieren würdest.
Entweder du benutzt direkt ein 2-dimensionales Array (so ähnlich wie du es bereits mit Stringsplit() gelöst hast) , oder du schreibst sämtliche Beschreibungen in eine Zeile und dröselst diese per Stringsplit auseinander.

wird ersetzt durch

Weiterhin gibt es die Möglichkeit, einer Funktion Parameter mitzugeben.
Du fragst bei WASD jede Taste in einer Funktion ab, das ist unnötig und bläht den Code auf!

Ich würde eine "Universalfunktion" machen...(in Ermangelung der Maps nicht testbar, du solltest aber sehen woran du schrauben musst^^

Dein Problem wird nämlich werden, dass du Aufgrund der Menge an Code nicht mehr richtig durchblickst. Anderst du ggf. deine Geländeform, musst du hunderte Zeilen Code Hinzufügen oder Ändern. Da ist es wesentlich einfacher, eine Funktion zu schreiben, welche eine Erweiterung deiner Geländemapdatei einfach mit umsetzt.
Der Programmcode sollte so geschrieben sein, dass Änderungen an externen Dateien automatisch umgesetzt werden.

Das ist ja cool....
Ich habe hier zuhause auf dem Rechner einen Test geschrieben, da ist es genau umgekehrt^^ Excel ist 3-4x schneller!

Sub Test()


Dim zeile As Integer
Dim spalte As Integer




For zeile = 5 To 1000   'tabelle füllen
    For spalte = 1 To 50
        ActiveSheet.Cells(zeile, spalte).Value = zeile & spalte
    Next
Next


'ab hier testen


For zeile = 5 To 1000
wert = ActiveSheet.Cells(zeile, 3).Value
ActiveSheet.Cells(1, 1).Value = wert
Next




End Sub

Sofort dieselben Scripte auf dem Firmenrechner laufen lassen.... Excel um LÄNGEN langsamer...wtf...werde wohl mit dem Admin mal sprechen müssen