Probleme mit gehookter GetSaveFileName aus ComDlg32.DLL

[BeeJay]

Ich habe diese Funktion aus der ComDlg32.DLL gehookt, um den Download von ca. 20-70 PDF Dateien von einer HTTPS Seite automatisieren zu können. Dieser Hook erspart mir aus das Auswählen von Verzeichnis und Dateinamen.

Sollte er jedenfalls machen. Der Hook funktioniert einwandfrei und wenn ich einen Link auf der entsprechenden HTML-Seite anklicke, wird auch meine gehookte Funktion aufgerufen (steckt in einer DLL), welche testweise so aussieht:

***

function NewGetSaveFileNameW(var OpenFile: TOpenFilenameW): Bool; stdcall;
var
FLen: integer;
FExtLen: integer;
FileName: WideString;
begin
FileName := 'C:\TESTFILE.ZIP';
FLen := Length(FileName);
FExtLen := Length(ExtractFileExt(FileName));
OpenFile.nFileOffset := FLen-Length(ExtractFileName(FileName));
if FExtLen = 0 then
OpenFile.nFileExtension := 0
else
OpenFile.nFileExtension := FLen-FExtLen+1;
OpenFile.lpstrFile := PWideChar(FileName);
Result := True;
end;

***

Seltsamerweise wird der neue Dateiname aber nicht angenommen.

Wo liegt der Fehler? Quäle mich heute schon den ganzen Tag damit rum :-(

[Hagen Reddmann]

Hi

Jaja, Du kannst nicht eine Funktion "hooken" und dann auf alle DELPHI High-Language-Features zurückgreifen.
Wenn ich es richtig sehe nutzt Du WideString und das heist dynamische Allozierungen unter nutzung des Speichermanagers.
Am besten mal alles entkernen und einfach ein BEEP rein. Dann Step by Step alles hinzugefügt NUR mit PChar's, Windows-API Funktionen.

Gruß Hage

[BeeJay]

Es ist so, daß diese gehookte Funktion genau das macht was ich will, allerdings nicht dann, wenn sie von der Funktion DoFileDownloadEx aus ShDocVw.DLL aufgerufen wird.

Mein Testprogramm ruft einmal CommDlg.GetSaveFileNameW auf und da funktioniert es wie erwartet.

Rufe ich allerdings die exportiere Funktion DoFileDownloadEx auf, dann wird der neue Dateiname (in TOpenFileNameW-Struktur) nicht akzeptiert beim Download und der Vorgabename/-verzeichnis verwendet.

Mit PChars hatte ich allerdings nur Fehlermeldungen da GetSaveFileNameW aufrufen wird

[BeeJay]

Hast irgendwie recht, auch wenn ich es nicht verstehe, daß es beim Aufruf von GetSaveFileNameW geklappt hat.

Habe folgendes geändert und es funktioniert jetzt auch mit DoFileDownloadEx:

ALT:
OpenFile.lpstrFile := PWideChar(FileName);
NEU:
StringToWideChar(FileName, OpenFile.lpstrFile, OpenFile.nMaxFile)

[Hagen Reddmann]

Hi

Du arbeist mit gehookten DLL Exporten. D.h. eine andere DLL die zwar Deinem Process zugeordnet ist ABER einen komplett anderen Speichermanger nutzt wird nicht funktionieren wenn Du im Hook Dich auf den Delphi-Code (MM) verlässt. ALLES im Hook muss OHNE Delphi MM o.ä. auskommen, zumindestens wenn es um die Paramter Ein-/Ausgabe geht. Die DLL alloziert ja in IHREM Speicher alle Daten und erwartet sie auch dort.

Gruß Hagen

PS: das es mit Deiner Testfunktion klappte ist also logisch. Der Hook UND die Testfunktion liegen im selben Prozess und Modul. Deshalb können beide auch alle Delphi MM Funktionen nutzen. Gefährlich wirds immer dann wenn Du eine nicht-Delphi DLL importierst die wiederum eine DLL importiert und erst diese dann Deinen Hook, indirekt durch Deinen Prozess ausgelösst, aufruft

[BeeJay]

Hallo Hagen

also so ganz gerafft habe ich es noch nicht.

Also mein Testprogramm hat eigentlich nur 2 Buttons auf der Form, wovon einer CommDlg.GetSaveFileNameW und der andere ShDocVw.DoFileDownloadEx aufruft. Sonst ist da nichts drin.

Dieses Programm habe ich gestartet, also noch nicht den Hook installaiert.

Danach starte ich ein anderes Programm welches den Hook installiert und zwar genau für obiges Testprogramm, deren PID ich vorher ermittle.

Die gekookte Funktion selbst in in einer getrennten in Delphi 5 geschriebenen DLL. Da mache ich jetzt eigentlich nichts anderes, als vom Vorgebenen Namen nur den Dateinamen zu nehmen und diesem einen anderen Pfad zu geben.

Also warum ich nicht gleich auf die Idee mit der kleinen Änderung kam,
weiß ich auch nicht mehr so. Für mich liegen halt Hook in DLL und Testfunktion in EXE und somit hat jedes Modul seinen eigenen Speicherbereich. Und die gehookte Funktion liegt wieder in einen anderen DLL. Ob jetzt die EXE meine Delphi DLL aufruft oder die ShDocVv.DLL war für mich eigentlich gleich.

Egal. War gestern auch schon ziemlich mit den Nerven fertig. Man sollte dann einfach eine Auszeit nehmen. Und wie Du siehst, habe ich heute von Deiner Anwort um 12:02 Uhr nur 19 Minuten gebraucht, um alles noch mal zu überdenken und zum Laufen zu bekommen.

Jedenfalls ist dieses neue Programm jetzt eine große Hilfe für mich. Ich muß täglich mehrere PDF-Dateien (bis zu 70 manchmal) von einer HTTPS Seite laden, wobei die PDF-Dateien aber On-The-Fly mit iText erzeugt werden. Eine andere Möglichkeit den Download selbst zu steuern funktioniert nicht, wie man es sonst beim Download (zum Beispiel mit NMHTTP.Get) gewohnt ist. Auch mit IPWorks5 SSL funktionierte das nicht. Jedes downloaden benötigte 3 Mausklicks zum laden der PDF-Datei ins Acrobat-Reader Plug-In, dann ausdrucken usw.

Nun kann ich von allen IHTMLElementen welche auf solche PDF-Dateien zeigen die ensprechenden Click-Funktion aufrufen und die Datei wird unter dem Namen und dort wo ich es will gespeichert.

Vorher habe ich noch das Plug-In deakviert durch einen Eintrag in der Registry, den ich nach dem Download aller PDF-Dateien wieder zurücksetze.

Fürs das Drucken schreibe ich mir noch einen Batch-Job oder ich werde mir mal das ActiveX von Acrobat Reader bzw. dessen SDK (19 MB, habe ich gerade runtergeladen) ansehen.

Gruß

BeeJay

PS: Der letzte Satz in Deinem PS ist wohl der Grund warum in meinem Testprogramm GetSaveFileNameW funktioniert und DoFileDownloadEx nicht