Beiträge von PSblnkd

Kanashius & funkey

Danke für Eure Hinweise.

Tatsächlich - von BASS hatte ich auch schon mal was gelesen, mich aber noch nie damit beschäftigt.

Durch das riesige Funktionsangebot muß man jedoch erst mal durchsteigen ... sicherlich wird die eine oder andere Funktion für den "FX2"-Nachbau geeignet sein.

Gibt es eigentlich schon eine "eingedeutschte" Version der BASS-UDF?

Übrigens - die DirectSound-UDF gibt es wirklich von "eukalyptus" - und auch UDFs zu Direct2D und Direct3D ...

Bei einem "FX2"-Nachbau sind nicht nur Sound-relevante Dinge zu bearbeiten, sondern auch Grafik. Die einzelnen grafisch dargestellten Funktionsblöcke werden funktional mit Linien verbunden, die auch dann erhalten bleiben, wenn die Funktionsblöcke auf dem Bildschirm verschoben werden. Das Ganze in einer .exe < 1MB! - Das war zu damaliger Zeit schon eine Leistung!

Grüsse aus Berlin

PSblnkd

Irgendwo hatte ich mal gelesen, daß es eine UDF-Implementierung für AutoIt zu dem bekannten Windows-AddOn "DirectX" gibt.

Damit sollte es möglich sein, Audiosignale programmtechnisch zu bearbeiten.

In den 1990ern gab es mal ein Windows-Programm "FX2", mit dem man sehr viel anstellen konnte - von der einfachen Signalerzeugung bis hin zu komplexer Signalbearbeitung, wie z.B. Echo und Reverb. Anbei mal ein SceenShot ...

Die Frage wäre jetzt, ob man sowas mit AutoIt unter Zuhilfenahme der besagten UDF "nachempfinden" könnte. Eine GUI dafür zu entwickeln, wäre sicherlich nicht so schwierig, aber diese dann mit Leben zu erfüllen ...?

Grüsse aus Berlin

PSblnkd

chrisbyRRC

Natürlich habe ich den Quellcode noch - will schließlich irgendwann, wenn wieder Zeit dafür ist, weiterarbeiten.

Die verbalen Beschreibungen waren wohl nicht ausreichend ...?

Am besten ist, Du kontaktierst mich via eMail.

Grüsse aus Berlin

PSblnkd

Hallo chrisbyRRC,

vor langer Zeit - beginnend 2010 - hatte ich mich mal ausgiebig mit "Grafik für AutoIt" beschäftigt: "Wir bauen uns ein CAD"

Wir bauen uns ein CAD

Es ist ein recht langer Thread, aber mangels allgemeinen Interesse habe ich das dann unterbrochen ... d.h. bis heute nicht weiter bearbeitet.

Das Flacker-Problem und das mit dem Löschen einzelner Grafiken (Linie, Rechteck usw.) hatte ich auch.

Schau Dir einfach mal an, wie ich das gelöst habe ...

Grüsse aus Berlin

PSblnkd

Professor Bernd

Das steht doch im Anfangs-Post:

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

Wie gesagt - mein Programm "Outlook Express(OE) Repair-Tool" funktioniert soweit - nur das Problem mit der While - WEnd-Schleife ist noch anhängig.

Demnächst werde ich den Entwicklungsbericht auf meine HP bringen - dann kann jeder nachlesen, wie ich das im Detail gemacht habe.

Grüße aus Berlin

PSblnkd

Danke "water".

Nach einigen Wochen Arbeit - nein, nicht durchgängig - ist es mir doch gelungen was Brauchbares zu programmieren.

Dazu gibt es eine GUI nebst Grundfunktionen - das ist trivial.

Auf der GUI ist auch kurz und knapp die Verfahrensweise erläutert. - Würde gern ein Bild dazu posten -> leider erfolglos.

Die wesentliche UP-Funktion ist diese:

Func Transfer_Run()
;
Local $FileList, $Input1
$Input1 = GUICtrlRead($Input1_ID)                                            ; der Inhalt des Input-Controls
$FileList = _FileListToArray($Input1)                                        ; zum ersten Mal
While $FileList[0] > 0
    ShellExecute($Input1 & "\" & $FileList[1], "", @ScriptDir, "open")       ; eMail aufrufen
    Sleep(1500)                                                              ; sonst gehen die Send-Befehle nicht
    Send("!dv")                                                ; ALT "Datei" -> "Verschieben" - DialogBox öffnet sich
    Send ("{ENTER}")                                                         ; DialogBox schließen – Ausführen
    Sleep(2000)                                                    ; ggf. raus ??? - nein -> verlängern auf 2000!
    ;
    If $FileList[0] > 0    Then                                    ; nur wenn noch eine eMail im Array vorhanden ist!
        $FileList = _FileListToArray($Input1)   ; muß nach jedem Transfer neu aufgerufen werden, da FileList dann neu
    Else
        ExitLoop
    EndIf
WEnd
ProcessClose($OE_ID)                                                                    ; OE beenden
;
EndFunc

Auf den Code für die GUI und die anderen Func-UPs will ich hier verzichten - kann in der Entwicklungsbeschreibung nachgelesen werden.

Soweit funktioniert das ganz gut - allerdings wird die While - WEnd-Schleife zum Schluss mit einer Fehlermeldung abgebrochen, obwohl noch eine IF - Then-Abfrage eingefügt wurde. Nebenwirkung:

Dadurch wird der (unsichtbare) OE-Prozess nicht beendet und OE kann nicht mehr normal gestartet werden ...

Sicherlich ist die Lösung nicht optimal - und sicherlich wird es Leute geben, die das viel besser und eleganter lösen wurden ...

Grüße aus Berlin

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/f…-hooking-injecting-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/f…-hooking-injecting-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/f…fter=any&sortby=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