✔ MSHTML.DLL,PrintHTML verhackt Dateiname

[DrMueller]

Hallo Leute,

mal wieder ein Problem mit dem HTML-Drucken. Neuerdings wird der Dateiname ganz merkwürdig verhackt. Dies fällt erst dann richtrig auf, wenn dann auf ein PDF-Drucker gedruckt wird, welcher die Datei speichert.
Unser Code:

 cWinSysDir = String(254, " ")                                       'MLHIDE
  Call GetSystemDirectory(cWinSysDir, Len(cWinSysDir))
  cWinSysDir = Trim(Left(cWinSysDir, InStr(cWinSysDir, Chr(0)) - 1))
  If Dir(cWinSysDir & "\MSHTML.DLL") <> "" Then                       'MLHIDE
    ProcessId = Shell("rundll32.exe " & cWinSysDir & "\MSHTML.DLL,PrintHTML " & Chr(34) & FN & Chr(34), vbNormalFocus) 'MLHIDE
    hProcess = OpenProcess(PROCESS_QUERY_INFORMATION, False, ProcessId)
    
    If hProcess <> False Then
      Dim cnt As Long
      Do
        Call GetExitCodeProcess(hProcess, ExitCode)
        DoEvents
        cnt = cnt + 1
      Loop While ExitCode = STATUS_PENDING
      Call CloseHandle(hProcess)

Als Filename geben wir eigentlich immer den ganzen Pfad an. Ein Beispiel:

C:\Users\MM\AppData\Local\Temp\cns\cnswork\readonly\PrintHTM121550.htm

Wenn dies dann gedruckt wird, erhält der PDF-Printer folgenden Dateinamen:

C:\Users\MM\Desktop\C4_file____C__Users_MM_AppData_Local_Temp_cns_cnswork_readonly_PrintHTM121550.pdf

Also ignoriert er den Pfad komplett und nimt den Desktop Pfad.

Ich habe versucht einfach mal die Slashes und Backslashes auszutauschen. Ausserdem habe ich versucht, testweise nur den Dateinamen anzugeben, da bekomme ich dann folgendes:

C:\Users\MM\Desktop\C4_res___ieframe.dll_PrintHTM121938.pdf

Das Problem ist, dass ich da anscheinend nach der Übergabe nichts mehr machen kann, da ich mich nicht zwischen HTML und Printer stellen kann. Mache ich bei der Übergabe irgend etwas falsch, oder hat sich evtl. mit W7 da was geändert?

Ich habe W7 64 Bit OS.



Wie immer vielen Dank für alle Ideen.


Müller Matthias

 

[Zvoni]

Was benutzt du als PDF-Drucker? Mir kommt das vor als ob ihr den Input-Namen als Output-Namen übergebt, und da knallts dann natürlich.

 

[DrMueller]

Hat eigentlich nichts mit dem PDF-Drucker zu tun. Man druckt ja auch nicht so unendlich oft html, und wenn das an den Drucker geht, dann sieht man oftmals den Dateinamen auch nicht richtig. Es fällt vor allem beim PDF Drucker auf, wo man dann die Datei speichert.

Soweit ich das sehe, ist der Fehler tatsächlich bim printhtml, die Frage ist, wieso ändert er den übergebenen Pfad komplett resp. ersetzt die Slashs und Backslashs einfach so.

 

[Zvoni]

Ich musste mal was ähnliches machen, allerdings aus Word-VBA heraus.
Das Problem dabei war, dass im Zuge des PDF-Druckers ich zuerst eine PostScript-Datei erstellen musste, um dann daraus per PDF-Drucker ein PDF zu erzeugen. Zu diesem Zweck ist bei uns der GhostScript installiert.

Wenn euer PDF-Drucker auch so funktioniert, kann es sein, dass vielleicht der GhostScript den Dateinamen vermurkst.

Frage: Funktioniert der html-Druck an einen normalen Papierdrucker?
Falls ja, hat printhtml nichts mit dem vermurksen des Dateinamens zu tun. Weil dann tippe ich eher auf eine Standardverzeichnis-Einstellung von GhostScript (falls installiert) bzw. des PDF-Druckers.

Dieses Umbiegen auf den Desktop sieht für mich stark nach ner Standardverzeichnis-Einstellung des PDF-Druckers/GhostScripts.

Beispiel:
Standardverzeichnis im PDF-Drucker ist
C:\Users\MM\Desktop

nach deinem Beispiel oben zu urteilen, wird euer Input-Name ("c:\Users\MM\AppData\blablablabla")
direkt an dieses Standardverzeichnis drangehängt. Die "4" im C4 kommt wahrscheinlich vom Doppelpunkt hinter C ("c:\") da ja Doppelpunkte in Dateinamen bekanntlich nicht erlaubt sind. Warum jedoch dann die Backslash's rausgehauen werden wüsste ich jetzt im Moment auch nicht.

 

[DrMueller]

Kommt auf jeden Drucker so, daher ists garantiert das printhtml.
Frage: Was erwartet diese Funktion denn als erster Parameter genau?

 

[Zvoni]

For example, the command to print an HTML page is:

rundll32.exe mshtml.dll,PrintHTML "<document>" "<driver>" "<device>" "<port>"

Gefunden hier: http://blogs.msdn.com/b/fyuan/archi...document-writer-without-user-interaction.aspx

EDIT: Mal ne andere Frage: Wieso geht ihr über Shell und rundll32 wenn es für die mshtml.dll eine Type-Lib gibt, auf welche man dann direkt verweisen kann? Microsoft HTML Object Library.

Ich hab sie mal schnell bei mir eingebunden, und nen Haufen Klassen und Methoden gefunden. Ausserdem bin ich mir relativ sicher (ist aber nur ne Vermutung!), dass man auf diese Weise den Druckerdialog unterdrücken kann (siehe auch dein anderer Thread dazu)

 

[Zvoni]

Mir ist gerade ein Verdacht gekommen: Übergebt ihr den Dateinamen in der normalen Schreibweise oder in URL-Notation?

Alle Beispiele die ich im Netz gesehen habe, verwenden nämlich die URL-Notation ("file://c:/Users/MM/blablabalba")

EDIT: bin über das hier gestolpert. Ist Freeware

http://www.printhtml.com/

 

[DrMueller]

file://C:\Users\MM\AppData\Local\Temp\cns\cnswork\readonly\PrintHTM123236.htm
file://C:/Users/MM/AppData/Local/Temp/cns/cnswork/readonly/PrintHTM123324.htm
file:\\C:/Users/MM/AppData/Local/Temp/cns/cnswork/readonly/PrintHTM123557.htm
file:\\C:\Users\MM\AppData\Local\Temp\cns\cnswork\readonly\PrintHTM123714.htm

Leider immer noch kein Erfolg.
Andere Frage: hast du mal so ein Beispiel das du gefunden hast? Evtl. liegt es ja nicht mal am Name, sondern an der Datei oder ähnliches, wenn ich einen Namen nachstelle der geht, finde ich das raus.

 

[Zvoni]

finde jetzt auf Anhieb auch grad kein passendes Beispiel (Bin auf Arbeit und kann nicht so ohne weiteres rumsurfen )

Hab aber dafür was anders gefunden:
Und zwar gibts anscheinend ein Problem, wenn man per rundll32 eine 64-bit dll aufruft. Ist das Zielsystem ein 64-Bit-System, so ist die mshtml.dll eben auch ne 64-Bit. Das könnte zumindest ein Grund sein, warum es knallt.

In diesem Zusammenhang wurde empfohlen, generell rundll32 zu vermeiden, und besser per LoadLibrary und deren Schwestern zu arbeiten

Private Declare Function FreeLibrary Lib "kernel32" (ByVal hLibModule As Long) As Long
Private Declare Function LoadLibrary Lib "kernel32" Alias "LoadLibraryA" (ByVal lpLibFileName As String) As Long
Private Declare Function GetProcAddress Lib "kernel32" (ByVal hModule As Long, ByVal lpProcName As String) As Long
Private Declare Function CallWindowProc Lib "user32" Alias "CallWindowProcA" (ByVal lpPrevWndFunc As Long, ByVal hWnd As Long, ByVal Msg As Any, ByVal wParam As Any, ByVal lParam As Any) As Long

Private Sub Main(HTMLDatei As String, AusgabeDrucker As String)
On Error Resume Next
'We're going to call an API-function, without declaring it!
Dim lb As Long, pa As Long
'map 'mshtml' into the address space of the calling process.
lb = LoadLibrary("mshtml")
'retrieve the address of 'PrintHTML'
pa = GetProcAddress(lb, "PrintHTML")
'Call the PrintHTML-function
CallWindowProc pa, HTMLDatei, AusgabeDrucker, ByVal 0&, ByVal 0&
'unmap the library's address
FreeLibrary lb
End Sub

Ein Versuch kann nicht schaden denke ich.

 

[DrMueller]

Die Idee ist gut, aber laut Beispiel wird die HTMLDatei als hWnd übergeben.