Beiträge von PSblnkd

Eigentlich wollte ich an dem Thema weiterarbeiten:
RE: Hooking & DLL-Injection

aber wie immer im Leben - es kommt noch was Wichtigeres dazwischen.

Bitte nicht gleich steinigen - mein BS ist immer noch WinXP incl. Outlook Express (OE) und das läuft seit 2003 zur vollsten Zufriedenheit (mal abgesehen von den Internet-Querelen) - seit einem Jahr sogar mit einer SSD.

Doch nun zum Problem:

Seit ein paar Tagen sind einiger der Ordner im OE mit hunderten von eMails komplett leer oder existieren plötzlich gar nicht mehr.

Die betreffenden dbx-Datein sind aber noch vollständig (?) erhalten.

Im Internet gibt es eine Reihe von Reparatur-Tools, die mehr oder weniger komfortabel funktionieren, aber allesamt nicht kostenlos sind -

mit einer Ausnahme: Mail-cure.

Damit kann man zwar händisch immer nur eine Mail aus der betreffenden dbx-Datei zurückholen, aber nicht direkt wieder in den leeren oder neu zu erstellenden OE-Ordner überführen.

Nun dachte ich mir - das wäre eigentlich eine AutoIt-Aufgabe und deshalb meine Anfrage:

Hat das schon mal jemand von Euch gemacht? -

Gibt's dazu Erfahrungen, fertige Skripte (man muß ja das Rad nicht nochmal erfinden ...)?

Die Such-Funktion zu "Outlook-Express" brachte zwar ein paar Mal Resultate, aber zum Reparatur-Problem habe ich nichts gefunden.

Grüße aus Berlin

PSblnkd

Nun gibt es neuerdings eine andere Dbug.au3 -> _dbug.au3 mit 119KB statt

34kB.

Leider fehlt mir hier eine weitere Include-Datei: WinAPISysWin.au3. Eine

Downloadquelle habe ich bislang nicht gefunden - nur, dass auch Andere auch

danach suchen ...

Möglicherweise liegt es an der AutoIt-Version. Ich arbeite immer noch mit

3.3.4.0. Die neuste zu installieren ist vielleicht wegen WinXP nicht

möglich - hatte ich mal in einem Forum-Beitrag gelesen.

Grüsse aus Berlin

PSblnkd

Hat schon mal jemand das AutoIt-Tool "DBug" versucht?

Wenn man im SciTE die Dbug.au3 läd und mit "Go" startet, kann man eine "schöne" GUI sehen.

Nur leider leuchtet mir nicht ein, wie ich daraus in den Debug-Modus für eine z.B. "Test.au3" kommen kann.

Wenn ich nach Beitext-Anweisung die Dbug.au3 in die Test.au3 includiere, und das Ganze dann wieder unter SciTE starte, kommt keine GUI mehr, sondern nur noch eine Fehlermeldung, dass die Datei Dbug_Test_tmp.au3 nicht erstellt werden konnte.

Was soll man mit solcher lapidaren Fehlermeldung anfangen?

Grüsse aus Berlin

PSblnkd

Professor Bernd (25.03.2020)

Vielen Dank für Deine Ausführungen.

(Zitat) "Ganz fasziniert bin ich davon, dass in SciTE Angaben zu Variablen als Tooltip erscheinen, wenn du mit der Maus drüber fährst."

Wie und unter welchen Umständen soll das gehen? - Bei mir passiert gar nichts, wenn ich in SciTE mit der Mouse über eine Variable fahre ...

oder erst mit integriertem "DBug" ?

Ich habe mir jetzt die 1.10er Version vom ISN AutoIt Studio heruntergeladen - weil dort das Debug-Tool "DBug" integriert sein soll.

Am 13.04.2020 hatte ich dazu in RE: ISN AutoIt Studio ein Statement geschrieben.

Und auch im Forum vom ISN AutoIt Studio - https://www.isnetwork.at/forum/viewtopic.php?f=7&t=168 ...

Christian hat jetzt geantwortet ... muss ich aber erst noch verarbeiten ... vielen Dank schon mal!

Grüsse aus Berlin

PSblnkd

Vor einiger Zeit hatte ich mir schon mal die Version 0.65 runtergeladen - bin aber nie zum Testen gekommen.

Jetzt aber - mit der neuen 1.10 wollte ich's nun endlich wahr machen. Vor allem deshalb, weil dort das Debug-Tool "DBug" integriert sein soll.

Nach Installation und der etwas nervigen Programmeinstellungs-Arie (mußte ich 2x machen, weil ich einen Hinweis falsch verstanden hatte) gibt es dann auch im Menü "Tools" das Untermenü "Debugging" und dort "Erweitertes Debugging mit DBug". Das kann man dann aktivieren oder deaktivieren - aber wie dann weiter? Ich habe den Einduck - das Feature geht noch gar nicht, oder habe ich da was übersehen?

Die Menü-Gestaltung ist m.E. ziemlich unübersichtlich - vielleicht sollte man sich besser an gewohnte Szenarien halten - wie z.B. in VB/VBA.

Zu einigen weiteren kleineren Problemen will ich (jetzt noch) nicht eingehen ...

Ansonsten kann ich nur den Hut ziehen - alle Achtung!

Und ich weiß, wovon ich rede, Schließlich habe ich auch schon umfangreiche AutoIt-Progamme geschrieben (CAD, Mediathek u.e.m.) und bin auch weiterhin "am Ball" - siehe Hooking & DLL-Injection.

Grüsse aus Berlin

PSblnkd

(So'n Mist - das hatte ich gestern schon geschrieben, war aber irgendwie nicht abgesendet ...)

chesstiger

Da kann ich Dir im Wesentlichen beipflichten.

In "Debugger für AutoIt3 - sinnfrei oder sinnvoll?" hatte ich mein Statement zum AutoIt-Debugger dargelegt.

BugFix

Im Schrittbetrieb o.g. VBA-IDE wird m.E. jede Zeile einzeln interpretiert und die dazu gehörenden Ausgaben gemacht - natürlich in Abhängigkeit weiter oben liegenden Zeilen. Variable, die erst weiter unten vorkommen, sind (nach Deklaration) natürlich (noch) leer.

Bei Schleifen kann man mittels Haltepunkt am Anfang oder Ende der Schleife sehr schön die Werte-Entwicklung der Variablen - auch von Objekt-Variablen beobachten. Das kann weder eine Consolen-Ausgabe noch MsgBoxen ...

Aber jetzt muss ich mich wieder dem eigentlichen Thema zuwenden ... Hooking & DLL-Injection.

Sollte es neue Erkenntnisse geben ... gibt's neue Postings ...

Edit:

Die ersten Erkenntnisse: - So einfach ist das wirklich nicht!

Bisher ist es mir noch nicht gelungen - außer das Bsp. von Fremde GUIs und Controls? nach zu vollziehen - einen "Hook" auf ein Control einer fremden GUI hin zu bekommen. Die Quelle https://www.autoitscript.com/forum/topic/87…njecting-a-dll/ ist sehr kompliziert und für mich schwer zu verstehen - da wäre eine IDE mit integriertem Debugger wirklich sehr hilfreich!

Wir werden sehen ...

Grüsse aus Berlin

PSblnkd

Danke an Professor Bernd!

DBUG (Another debugger for AutoIt ist noch so ein separater Debugger - so wie der von Steve Towner, der bei mir nicht läuft.

Trotzdem werde ich mir den mal anschauen ...

Warum bei AutoIt ein Debugger nicht sinnvoll sein kann - bzw. wie BugFix schreibt - bei der Skriptsprache AutoIt nicht gehen soll, will mir nicht einleuchten.

VBA ist doch auch eine Skriptsprache - oder? - Und da gibt es die wunderbare IDE (Editor mit Syntax-Highlighting, integrierten Debugger mit verschiedenen Fenstern, Objekt-Browser (Verweise) u.v.a.m.), aber leider ohne Compiler, mit dem man aus dem Skript eine .exe machen kann, die dann auf allen (?) Windows-Rechnern läuft und das ohne jewede Bibliotheken oder Frameworks wie bei AutoIt. In RE: Hooking & DLL-Injection hatte ich einen ScreenShot von der IDE gepostet ...

Für einfache Wert-Ausgaben von Variablen ist m.E. die Console zwar geeignet, aber - wie BananaJoe schon schrieb - mit einer MsgBox hält die Skriptabarbeitung an und das ist vielfach sehr nützlich! Beide Verfahren sind aber ungeeignet, wenn es sich um Objekt-Variablen handelt, deren innerer Aufbau oft sehr kompliziert ist. Siehe mein Problem mit einer Objekt-Rückgabe über COM, die bei AutoIt nicht richtig ankam ...

@ BugFiX: Beim Schrittbetrieb (STEP) wird Zeile für Zeile interpretiert, d.h. es werden auch nur die davor liegenen Codezeilen mit einbezogen - die nachfolgenden noch nicht und bei Schleifen kann man dann sehr schön die Variablen-Veränderungen beobachten ...

Warum sollte sich ein komfortabler Debugger nicht in SciTE integrieren lassen, wo es doch angeblich OpenSource ist?

Momentan habe ich leider dazu keine Zeit ... weil mit Anderem beschäftigt -> RE: Hooking & DLL-Injection.

Es würde mich sehr freuen, wenn demnächst SciTE mit integriertem Debugger zur Verfügung steht.

Grüsse aus Berlin

PSblnkd

BugFix vom 23.03.2020

"STEP" ist der Schrittbetrieb im Debuggermodus. In der VBA-IDE kann man dann im Lokalfenster die einzelnen Variablen - auch Objekt-Variablen - beobachten.

Anbei ein ScreenShot. Die gelb markierte Zeile ist die aktuelle. Außer dem Einzelschritt gibt es im Debuggermodus auch noch "Prozedurschritt", "Prozedur abschließen", "Ausführen bis Cursorposition", "Überwachung hinzufügen", Überwachung bearbeiten", Aktuellen Wert anzeigen", Haltepunkt ein/aus", "Alle Haltepunkte löschen", "Nächste Anweisung festlegen" und "Nächste Anweisung anzeigen".

Grüsse aus Berlin - und bleibt gesund!

PSblnkd

BugFix am Freitag

Betr. "die AutoIt-UDF _WinAPI_SetWindowsHookEx hat nichts mit der gleichnamigen WinAPI-Funktion zu tun" - da hast Du natürlich Recht! - Hier muss ich meine Aussage korrigieren. Mir war nicht geläufig, dass die WinAPI-Funktion in der user32.dll enthalten ist und diese über die UDF referenziert wird. - Wieder was dazu gelernt - Danke! -

Und danke auch für den Hinweis zum Suchwort "Hook" im deutschen AutoIt-Forum - da gibt es tatsächlich eine ganze Menge, wobei Vieles nicht mein Problem betrifft - "Fremde GUIs und Controls". Aber auch dazu bin ich fündig geworden:

RE: Fremde GUIs und Controls?

d.h. das ist jedenfalls schon mal ein Ansatz ...

Von Dir habe ich auch ein Code-Beispiel (leider nicht mehr die Quelle) vom 30.07.2014: "WM_Message Hook". Auch davon habe ich einige Infos erhalten.

"Hooking & DLL-Injection" von "arcker" https://www.autoitscript.com/forum/topic/87…njecting-a-dll/ scheint vielleicht das Richtige zu sein - muss ich aber noch durcharbeiten.

Bin dabei mir selbst ein Bild zu machen ... wie bei http://www.ps-blnkd.de/Control_Events_AutoIt.pdf.

@Yjug am Samstag

Danke für Deine Hilfsbereitschaft! - Die ist mir sehr willkommen.

Vielleicht hast Du ja Interesse an dem Projekt mitzuarbeiten:

http://www.ps-blnkd.de/Seite3.htm - Bereich "Bücher - CDs (2): PS-Buch "SDK-TurboCAD™ - ein Tutorial (Teil 2)".

Es werden dringend Co-Autoren gesucht ...

Ein weiteres Problem wäre die Erweiterung des SciTE-Editors (IDE) mit der Funktionalität "STEP" u.ä. - so, wie es bei der VBA-IDE üblich ist. Der separate AutoIt-Debugger läuft bei mir leider nicht ... und ich bin es leid immer mit unzähligen MsgBoxen zu arbeiten.

Grüsse aus Berlin

PSblnkd

BugFix

Danke für Deine Hinweise.

Soweit ich das verstanden habe, betrifft "Änderungen vornehmen" das Eingreifen in die exe-Programmdatei, wie etwa das "Patchen" von einzelnen Bytes, um z.B. einen Passwortschutz o.ä. "auszuhebeln". Das ist hier aber nicht meine Absicht!

Es soll hier lediglich der durch Windows vorgegebene Programmablauf geändert werden.

Auch in Windows selbst kann durch DLL-Injection Zusätzliches oder - leider auch - Gegensätzliches bewirkt werden. Beispielweise kommt im Kontextmenü des Win-Explorers ein zusätzlicher Menüpunkt, wenn das Packerprogramm "winzip" oder "7-zip" installiert wurde.

Wenn das nicht erlaubt wäre, gäbe es auch nicht die diesbezüglichen WinAPI-Funktionen.

Was ich nicht verstehe - die AutoIt-UDF _WinAPI_SetWindowsHookEx hat nichts mit der gleichnamigen WinAPI-Funktion zu tun, d.h. sie basiert nicht auf deren Grundlage. Bisher war ich immmer noch der Ansicht, dass die UDFs des "WinAPI Management" einen Teil der in AutoIt umgesetzten WinAPI-Funktionen sind.

Im englichen Forum gibt es haufenweise Hinweise zu _WinAPI_SetWindowsHookEx:

https://www.autoitscript.com/forum/search/?…ortby=relevancy

Wenn sich hier im deutschen Sprachraum noch niemand damit befasst hat, werde ich mich wohl oder übel durch den englischen Wust wühlen müssen ...

Grüsse aus Berlin

PSblnkd

Die Aufgabe ist im Menü einer bestehenden Win-Prog einen Eintrag zu ändern, bzw. mit neuer Funktionalität zu versehen, oder auch eine zusätzlichen Menüpunkt für erweiterte Funktionalität zu implementieren.

Dazu hatte ich gelesen, dass das ggf. mit den AutoIt-UDFs:

- _WinAPI_SetWindowsHookEx,

- _WinAPI_CallNextHookEx,

- _WinAPI_UnhookWindowsHookEx

(und ggf. noch andere) gehen soll.

Die diesbezüglichen Hilfe-Beispiele erschließen sich mir nicht wirklich, da sie kaum kommentiert sind.

Es soll aber auch noch andere Methoden geben ...

Hat sich schon mal jemand mit dieser - zugegebenermaßen komplizierten - Thematik befasst und wenn ja, mit welchem Ergebnis?

Grüsse aus Berlin

PSblnkd

BugFix

autoBert

Danke für Eure Bemühungen - habe ich jetzt getestet.

Entscheidend war das, was im BugFix-Code steht:

GUICtrlSetOnEvent(-1, '_TabEvent')

muss gleich nach der allgemeinen Tab-Definition

$IDTab = GUICtrlCreateTab(10, 10, 300, 150)

stehen und nicht erst nach der betreffenden, z.B.:

$TabItem1 = GUICtrlCreateTabItem('Item 1').

Dann geht die Event-Funktionalität auch für Tab, allerdings mit der Einschränkung, dass diese bei jedem Tab-Wechsel auftritt. Deshalb ist dann auch eine diesbezügliche Auswertung notwendig (wie im BugFix-Code angegeben).

Da das aber nicht wesentlich einfacher ist, werde ich bei der "Button-Hilfslösung" bleiben ...

Aber danke für den Erkenntnisgewinn!

Es wäre vorteilhaft, das in der AutoIt-Hilfe einzuarbeiten ...

Grüsse aus Berlin

PSblnkd

BugFix

Vielen Dank für Deine umgehende Antwort.

In dem von Dir angegebenen Hilfe-Beispiel kann ich keine Event-Aktivierung erkennen ...

Was meinst Du mit "auf die Tab-ID reagieren"? -> $tab bzw. $tab1 habe ich doch in GUICtrlSetOnEvent($tab1, "PS_List") verwendet - leider erfolglos .

Eine "Hilfslösung" mit Button ist derzeit auch im Einsatz. Es wäre aber viel eleganter, wenn beim Click auf die Tab gleich eine Reaktion ausgelöst werden könnte (wie bei den anderen Controls) -

oder geht das beim Tab-Control prinzipiell nicht?

Grüsse aus Berlin

PSblnkd

Für ein neues Programm habe ich auf einer GUI zwei Tabs integriert:

$TabGen = GUICreate("StLiGen", 500, 600, 300, 100)

$tab = GUICtrlCreateTab(0, 80, 500, 520)

...

$tab1 = GUICtrlCreateTabItem("Kalkulation")

Nun hätte ich gern, dass bei der Anwahl der Tab "Kalkulation" bereits eine Aktion stattfindet -

z.B. das Ausfüllen einer ListBox mit Daten:

GUICtrlSetOnEvent($tab1, "PS_List")

bringt aber leider kein Event, d.h. das UP "PS_List" wird nicht angesprungen.

Vor einiger Zeit hatte ich mich zwar schon mal ausgiebig mit den "Control-Events inAutoIt" beschäftigt ->

http://www.ps-blnkd.de/Control_Events_AutoIt.pdf -

nur eben noch nicht mit den Tabs auf einer GUI.

In der AutoIt-Hilfe habe ich nichts dazu gefunden ...

War damit schon mal jemand erfolgreich?

Grüsse aus Berlin

PSblnkd

water #12

Danke für Deine Bemühungen und den Tip zum TLBViewer - werde ich mir ansehen, wenn Zeit ist ...

Mit der Variante über Send(Key)-Sequenzen bin ich nicht klar gekommen, weil möglicherweise meine Tastastur was anderes ausgibt, als in der AutoIt-Hilfe dokumentiert.

Es hat ein Weilchen gedauert, aber jetzt habe ich die Lösung.

Von den über 400 (!) Properties zu PaperSpaces gibt es auch zwei, die direkt die Blattgröße ausgeben - und diese sind einfache Zahlen, so dass eine Kommunikation via COM möglich ist. Es ist lediglich der Objekt-Verweis auf das aktuelle, ggf. neu erstellte Blatt im Papierbereich zu verwenden - hier $PSnew.

$PaperBreite = $PSnew.Properties("PaperWidth").Value                                              ; Standardwert der Eigenschaft = 2100

$PaperHoehe = $PSnew.Properties("PaperHeight").Value                                              ; dito = 2970

$ret = MsgBox (4, "Papierbreite & Höhe", $PaperBreite & " " & $PaperHoehe & @CRLF & "Blattformat ändern?")

If $ret = 6 Then ; ja

$PSnew.Properties("PaperWidth").Value = $PaperHoehe ; das funktioniert !

     $PSnew.Properties("PaperHeight").Value = $PaperBreite

EndIf

Das Blattformat ist von Quer auf Hoch umgestellt.

Grüsse aus Berlin

PSblnkd

Hallo zusammen,

vielen Dank für Eure zahlreiche Teilnahme.

@BugFix-#5

Die Code-Variationen in der Iteration brachten kein anderes Ergebnis.

$PaperBreite = $BreiteHoehe(0)
$PaperHoehe = $BreiteHoehe(1)

Das hatte ich anfangs so gemacht (wie in VBA) und auch die direkte Indexierung

$PaperBreite = $activeDwg.Paperspaces.Item($PSnew.name).Properties(193)(0)

$PaperHoehe = $activeDwg.Paperspaces.Item($PSnew.name).Properties(193)(1) -

brachte dann zwar keine Fehlermeldung mehr, aber die beiden Variablen bleiben leer.

Als letzten Versuch hatte ich Folgendes probiert:

Local $BreiteHoehe = DllStructCreate("double;double;double")

$BreiteHoehe = $activeDwg.Paperspaces.Item($PSnew.name).Properties(193)

$PaperBreite = DllStructGetData($BreiteHoehe, 1, 1)

$PaperHoehe = DllStructGetData($BreiteHoehe, 1, 2)

Das Ergebnis von $PaperBreite $PaperHoehe: 0 0 - anstelle der erhofften Zahlen "210" und "270".

@water-#7

Leider gibt es nur wenig Doku über das TC-SDK und in Deutsch schon gar nicht!

Deshalb hatte ich schon vor Jahren damit angefangen etwas Licht in die "Tiefen und Höhen" der SDK-Programmierung bei TurboCAD zu bringen:

http://www.ps-blnkd.de/Seite3.htm#SDK

Jetzt bin ich am Teil 2: http://www.ps-blnkd.de/SDK-T2_Inh.pdf (nicht mehr aktuell) und an einem konkreten Programm "Stücklisten-Generator".

Fazit:

Vielleicht kann AutoIt über COM keine Array-Strukturen einlesen/senden?

Mit dem Englischen habe ich es leider nicht so, sonst würde ich mal im Autoscript-Forum eine Anfrage starten ...

So wie es jetzt aussieht, werde ich wohl Send(Key)-Sequenzen benutzen müssen ... wobei dabei auch noch nicht klar ist, ob das überhaupt geht, weil die TC-Befehle im Kontext-Menü nicht indexiert (Buchstaben unterstrichen) sind.

Grüsse aus Berlin

PSblnkd

Danke "water" & "BugFix"

In AutoIt ist es tatsächlich ein Object - wird in VBA allerdings als "Variant/Double(0to2)" ausgewiesen, so dass dort die Referenzierung wie o.g. recht einfach ist.

Somit könnte man annehmen, dass evtl. mit

$PaperBreite = $BreiteHoehe.Properties(0)

auf das 1.Element usw. referenziert werden kann - aber leider weit gefehlt ...

Die Idee von "BugFix" habe ich ausprobiert, aber auch da kommt eine Fehlermeldung:

"Fehlernummer 80020003 - WinDescription: Mitglied nicht gefunden"

Wie kann man denn auf ein Object in AutoIt referenzieren - aus der Hilfe werde ich nicht so recht schlau!

Und komme somit auch nicht weiter ...

Grüsse aus Berlin

PSblnkd

Die COM-Verbindung zwischen einem Anwenderprogramm - hier "TurboCAD" und AutoIt funktioniert eigentlich ganz gut, solange es sich um einfache Wert-Zuweisungen und -Rückgaben handelt (Zahlen und Text). 

Nun gibt es eine Funktion, die ein Array mit 3 Elementen (Zahlen) zurückgibt. 

In VBA funktioniert das:

BreiteHöhe = drw.PaperSpaces.Item(psN).Properties(193)

Breite = BreiteHöhe(0) ' = 210 

Höhe = BreiteHöhe(1) ' = 270

In AutoIt hingegen nicht:

$BreiteHoehe = $activeDwg.Paperspaces.Item($PSnew.name).Properties(193)

MsgBox(1, "Array?", IsArray($BreiteHoehe))

Die MsgBox sagt "kein Array" und demzufolge ergibt sich mit

$PaperBreite = $BreiteHoehe[0]

$PaperHoehe = $BreiteHoehe[1]

Fehler!

Warum wird in AutoIt kein Array erkannt - oder was mache ich falsch?

Grüsse aus Berlin

PSblnkd

Die Frage nach der AutoIt-Version für Linux war eigentlich nur nebenbei.

Der Hauptgrund meines Postings war der Hinweis auf das "LinuxLiveUSB"-Programm, welches vom Entwickler Thibaut Lauzière in AutoIt erstellt wurde. Da die Quellen beim Download dabei sind, hatte ich angenommen, dass das hier von Interesse ist ...

@Musashi

Mit "Wine" geht mehr, als nur "simple Skripts zum Laufen bringen". Allerdings gibt es jetzt für "Wine" einen umfangreichen Ersatz:

"PlayOnLinux" - damit soll sogar das Steuerprogramm "Elster" gehen ...

Grüsse aus Berlin

PSblnkd

Gibt es eigentlich eine "AutoIt"-Version für Linux oder ist eine solche in Arbeit?

Allerdings gibt es AutoIt-Programme für Linux - z.B.:

http://www.linuxliveusb.com

Damit kann man sich von einer Linux-Distribution einen Boot-fähigen USB-Stick erstellen und die Distribution ohne Installation auf dem PC verwenden.

Bei dem Download sind auch die AutoIt-Quellen dabei - ist sicherlich interessant, wie der Entwickler Thibaut Lauzière das realisiert hat ...

Grüsse aus Berlin

PSblnkd