Dateivorschau per Interface IPreviewHandler

    • VB.NET
    • .NET (FX) 4.5–4.8

    Es gibt 35 Antworten in diesem Thema. Der letzte Beitrag () ist von DTF.

      @GOKTerek Urlaub beendet. Deswegen ein erneuter Test. Funktioniert bestens. Auch mit Exceldateien (Office 365). Hier ein Link wie man die Preview von Officedateien reparieren/überprüfen kann: hasslinger.com/index.php/de/bl…ie-temp-umgebungsvariable

      Falls sich mal die Preview vom Edge für PDFs eingenistet hat, obwohl der AcrobatReader installiert und dieser der Standardbetrachter ist, dann folgende Reg importieren bzw selbst den Key ändern. Dann funktioniert auch die Preview mit den AcrobatReader wieder.
      ​ Windows Registry Editor Version 5.00 [HKEY_CLASSES_ROOT\.pdf\ShellEx\{8895b1c6-b41f-4c1c-a562-0d564250836f}] @="{DC6EFB56-9CFA-464D-8880-44885D7DC193}"
      Mfg -Franky-

      Hi @-Franky- ,

      erst mal ein fettes Lob für diesen Code.
      Bin jetzt erst dazu gekommen, diesen in mein Projekt einzubauen.
      Und was soll ich sagen - funzt perfetto. ^^
      Danke Dir recht sakrisch für das Publizieren dieser Klasse! :thumbsup:

      Aber ich habe hier keinen Hinweis gefunden, ob man diesen Code auch in eigene (kommerzielle) Software einbauen darf und falls ja, ob ein Hinweis in der Dokumentation auf Dich als Autor erforderlich ist.
      Kannst mich bitte schlau machen, wie Du das gehandhabt haben willst?

      Übrigens - bei den ersten Versuchen mit parallel geöffnetem App IPreview von Dir und meinem Projekt mit Deinem eingebundenem Preview-Script und wechselseitigem Aufrufen der beiden Apps unter Nutzung der Preview-Funktionen kam es zu einer Speicherschutzverletzung, welche das weitere Anzeigen von Doc-Previews (andere Formate funktionierten aber) verhinderte. Die PicBox zeigte dann bei Docs nur das Word-Symbol.
      Auch mehrfache Neustarts der beiden Apps brachten keine Abhilfe.
      Erst nach einem Rechner-Neustart und folgendem ausschliesslichen Start meiner Anwendung flutschte es wieder.

      Beste Grüsse

      Hi

      Klar kannst Du den Code in Deiner Software einbauen. Da das ganze gut durch MS dokumentiert ist wie es funktioniert, erhebe ich auch kein Anspruch auf Nennung als Autor. Kannst Du gern machen, ist aber kein muss.

      Zu dem Problem kann ich im moment nichts sagen. Ist mir bisher so, wie in Deiner Konstellation, nicht aufgefallen bzw. habe ich nie ausprobiert. Eventuell hab ich da noch einen Fehler im Code der einen PreviewHandler nicht korrekt beendet. Dann müsstest Du auch entsprechende Prozesse im Taskmanager sehen. Also für DOC müssten dann mehrere Word-Prozesse laufen die nicht korrekt beendet werden.
      Mfg -Franky-

      Superklasse!

      Danke Dir vielmals. :thumbsup:

      Das Problem tritt ja nicht auf, wenn nur meine App mit Deinem PreviewHandler läuft.
      Diese Situation passierte dann auch nicht wieder, nachdem ich Dein Script erfolgreich in mein Projekt eingekonotet habe und nur meine App am Start war.
      Vielleicht kommt mal von einem Kunden eine entsprechende Response.
      Solange warte ich mal...

      @-Franky-
      Aha, gerade nochmal erlebt...
      Hatte mein Projekt gestartet, darin den PreviewHandler benutzt und dann VS2022 beendet und das Inno-Setup zum Paket bauen gestartet.
      Dann habe ich das Installationspaket ausgeführt und die neu installierte Exe gestartet - Nur Symbol im Doc-Preview.
      Im Taskmanager waren noch Prozesse von Excel und Word aktiv.
      Nachdem ich beide abgeschossen hatte und die Exe erneut startete, war wieder alles prima.
      Scheint, als ob die Prozesse wirklich nicht beendet würden.
      Habe jetzt nochmal explizit

      VB.NET-Quellcode

      1. Preview.ClosePreview()

      in die "Mainform_FormClosing" eingefügt, aber dennoch bleiben die Office-Prozesse am Laufen.

      EDIT: Entwarnung...
      Nach einem Neustart meines Rechners und erneutem Testen klappt es nun - alle Office-Prozesse werden mit dem FormClosing beendet.
      Da hatte sich wohl was festgesetzt.
      Mein Preview.closePreview im laufenden Script wurde wohl unter ungünstigen Bedingungen (offenes Preview beim Schliessen der Anwendung) nicht ausgeführt.
      Jetzt scheint alles zu klappen.
      Bilder

      • PreviewHandler.jpg

        290,95 kB, 1.920×1.200, 31 mal angesehen

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Dideldum“ ()

      Hi @-Franky-
      Jetzt klappt alles fein mit Deinem IPreviewHandler - total stabil und ohne Probleme.
      Nur bekomme ich es nicht hin, dass beim Mainform.resizeEnd das vom IPreviewHandler generierte Bild in der PixBox entsprechend der neuen Abmessungen des Parent-Controls angepasst angezeigt wird.
      Könntest Du mir dazu vielleicht einen Tip geben?
      Wäre supernett ^^

      Also -Franky- callt die Funktion SetRect vom Interface in der Funktion ResizePreview, also probier mal wie in der Beispielmappe:

      VB.NET-Quellcode

      1. ' funktioniert nicht für alle Dateien
      2. Preview.ResizePreview(New Size(300, 300))
      Zitat von mir 2023:
      Was interessiert mich Rechtschreibung? Der Compiler wird meckern wenn nötig :D

      Servus @DTF
      Super, danke Dir!
      mit:

      VB.NET-Quellcode

      1. If tsc_WindowsViewer.Visible = True Then
      2. tsc_WindowsViewer_PictureBox.Size = tsc_WindowsViewer.ContentPanel.Size
      3. Preview.ResizePreview(New Size(tsc_WindowsViewer_PictureBox.GetPreferredSize(Me.Size).Width, tsc_WindowsViewer_PictureBox.GetPreferredSize(Me.Size).Height))
      4. End If

      im Resize klappt es perfekt :)

      Schönen Rest-Sonntag ^^

      Dideldum schrieb:

      Preview.ResizePreview(New Size(tsc_WindowsViewer_PictureBox.GetPreferredSize(Me.Size).Width, tsc_WindowsViewer_PictureBox.GetPreferredSize(Me.Size).Height))


      Mach das so:

      VB.NET-Quellcode

      1. Preview.ResizePreview(sc_WindowsViewer_PictureBox.GetPreferredSize(Me.Size))


      @-Franky-

      Hab da was gesehen:

      VB.NET-Quellcode

      1. Private Function CreateInterface(CLSID As String, IID As String) As IntPtr
      2. Dim pInterface As IntPtr = IntPtr.Zero
      3. If CoCreateInstance(New Guid(CLSID), IntPtr.Zero, CLSCTX_LOCAL_SERVER, New Guid(IID), pInterface) = S_OK Then
      4. Return pInterface
      5. ElseIf CoCreateInstance(New Guid(CLSID), IntPtr.Zero, CLSCTX_INPROC_SERVER, New Guid(IID), pInterface) = S_OK Then
      6. Return pInterface
      7. End If
      8. End Function


      Warum ein 2. mal CoCreateInstance callen, wenn es beim ersten mal nicht klappt? Wäre doch besser den HRESULT auszuwerten, und was passiert wenn es beide male nicht klappt? Es geben ja nicht alle Codepfade einen Wert zurück.
      Zitat von mir 2023:
      Was interessiert mich Rechtschreibung? Der Compiler wird meckern wenn nötig :D

      @DTF Ich hatte festgestellt das, insbesondere der PDF-PreviewHandler vom AcrobatReader, beim Initialisieren Probleme macht und daher der Fallback auf CLSCTX_INPROC_SERVER. Standard wäre in diesem Fall CLSCTX_LOCAL_SERVER. Daher der zweite Aufruf falls der erste fehlschlägt. Erst wenn beide Möglichkeiten fehlschlagen gibt die Funktion IntPtr.Zero zurück. Da die meisten APIs und Interfaces S_OK, in wenigen Fällen auch einen anderen hResult, als Erfolg zurückgeben, interessiert mich persönlich nicht so sehr warum hResult <> S_Ok war. Es gibt mit Sicherheit Ausnahmen wo man den hResult genauer untersuchen müsste um auf Fehler zu reagieren.
      Mfg -Franky-

      Huch, hab den Unterschied nicht gesehen, LOCAL und INPROC. Aber es fehlt trotzdem ein Return Statement. Wird das in VB nicht als Fehler gemeldet?(Oder hast du was in der Mappe umgestellt?) Mit C# würde das so nicht kompilieren.
      Zitat von mir 2023:
      Was interessiert mich Rechtschreibung? Der Compiler wird meckern wenn nötig :D

      DTF schrieb:

      Wird das in VB nicht als Fehler gemeldet?(Oder hast du was in der Mappe umgestellt?)
      Kann ich Dir im Moment gar nicht sagen. Komme gerade nicht an meinem Code. Aber wenn da was wäre, dann hätte ich schon beim erstellen des Code gesehen das da was im Argen ist. Umgestellt an der Mappe habe ich nichts.

      Edit: Oh, komme ja doch dran. Nope. VB zeigt hier keinen Fehler. :D
      Mfg -Franky-

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „-Franky-“ ()

      So, jetzt hab ich genug Kaffee drin. Hab die Frage falsch gestellt. Ich meinte sollte das nicht als Fehler gemeldet werden, wäre die richtige Frage gewesen. Hab ja deine Mappe runtergeladen und mal durchgeschaut, kann kompiliert und ausgeführt werden. Funktionen sollten immer was zurückgeben. In C# wird das als Fehler gewertet, was IMO auch richtig ist.
      Bilder

      • Unbenannt.jpg

        31,61 kB, 749×189, 28 mal angesehen
      Zitat von mir 2023:
      Was interessiert mich Rechtschreibung? Der Compiler wird meckern wenn nötig :D

      Weil bei fehlender Angabe (leider automatisch) IntPtr.Zero zurückgegeben wird. Bei vielen anderen Rückgabedatentypen wird gemeckert, dass ein Rückgabewert fehlt.
      Siehe stackoverflow, 1. Antwort
      Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

      Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

      Aha, eine komische Eigenart von VB. Hab das in C# statt mit nint nun auch mit IntPtr probiert, ich hatte das ja mit nint gemacht oben mit der Fehlermeldung(NativeSizedInteger, gibt es in VB nicht) . Aber beruhigend, das IntPtr da in VB eine Ausnahme ist, auch wenn das IMO unsauber ist.

      PS:
      Ist scheinbar mit allen ValueTypes so.
      Zitat von mir 2023:
      Was interessiert mich Rechtschreibung? Der Compiler wird meckern wenn nötig :D

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „DTF“ ()

    Facebook
    Telefonspende