Programmatisch PDF im PreviewControl anzeigen

Hallo,

laut Webseite kann nicht nur der Viewer, sondern auch die VorschauControls seit Version 26 PDFs anzeigen. Im eigenständigen List & Label Viewer funktioniert das tatsächlich über Datei/Öffnen. Wenn ich aber die eingebetteten Controls verwende und dort den FileName (im .net ListLabelPreviewControl) oder die FileUrl (bei direkter Verwendung des OCX-ActiveX-Controls) auf den Pfad eines PDFs setze, passiert gar nichts.

Frage: Wie kann man das PreviewControl dazu bewegen, neben *.ll Dateien auch *.pdf Dateien zu verwenden?

Danke,
Tris.

Hallo Tris,

leider lässt sich die Frage nicht ohne weitere Informationen beantworten. Das Verhalten bedarf einer genaueren Analyse durch unsere Entwicklungsabteilung. Aus diesem Grund würden wir Sie bitten, einen separaten Supportcase im Supportportal zu eröffnen und uns dort ideralerwesie ein Sample zur Verfügung zu stellen, mit dem wir das Verhalten auch bei uns reproduzieren können.

Sobald wir Ihnen einen möglichen Lösungsvorschlag anbieten können, würden wir Sie dann über das Supportportal benachrichtigen.

Vielen Dank für Ihre Mitarbeit.

Mit freundlichen Grüßen vom Bodensee

Als kleiner Nachtrag: ich habe das eben einmal in Version 28 getestet und dort das ListLabelPreviewControl verwendet - da kann ich (in meinem Fall im C# Viewer Sample) folgendes machen:

// Preload initial file
PreviewControl.FileName = statusBarPanel1.Text = Directory.GetCurrentDirectory() + "\\export.pdf";

Die Datei liegt natürlich auch im entsprechenden Verzeichnis und wird dann korrekt im Viewer angezeigt:

Insofern müssten wir herausfinden, was bei Ihnen anders ist, welche Version Sie verwenden usw. - das lässt sich vielleicht tatsächlich am besten über den Support klären. Das Ergebnis können Sie dann gerne auch hier wieder reinposten.

Hallo Kollegen,

gleich zwei so schnelle Antworten, vielen Dank.

@jbartlau: Ich habe es mit unserer L&L Version 27 getestet, die 28 ist bereits lizensiert, der Umstieg erfolgt allerdings erst demnächst … kann daran der Unterschied liegen?

Vielen Dank,
Tris.

Natürlich kann ich bei Bedarf auch einen SupportCase aufmachen.

Ah, wie doof - ich sehe gerade, dass ich zufällig im gleichen Verzeichnis auch eine export.ll liegen hatte. Der unterliegende Code scheint dann diese Datei geladen zu haben. Langer Rede kurzer Sinn - wir schauen uns das hier nochmal an.

1 Like

Hallo Herr Bartlau,

gibt es Neuigkeiten zum Thema? Wir wollen in Kürze ein Projekt umsetzen, in dem PDFs angezeigt werden. Hier würden wir gerne auf das Embedded PreviewControl von euch zurückgreifen.

Gruss,
Tris.

Hallo Tris,

wir sind aktiv am Thema dran :wink: . Das Problem ist, dass der Code für die PDF-Anzeige bisher nur in LlPreviewDisplay() “lebt”. Wir sind gerade dabei, diesen Code in eine eigene API zu gießen, die dann vom PreviewControl aufgerufen werden kann (automatisch). Wir werden das voraussichtlich in Version 28.001 freigeben, Sie können gerne vorab eine DLL mit den Änderungen erhalten - voraussichtlich Mitte der kommenden Woche sollten wir am Start sein.

Viele Grüße aus Konstanz!

1 Like

Works on my machine ™

1 Like

Hallo Herr Bartlau,

das sind ja großartige Neuigkeiten. Vielen Dank für die schnelle, unkomplizierte Bearbeitung. Wissen Sie schon, zu wann die 28.001 geplant ist? Auf die Vorabversion würden wir natürlich gerne zugreifen, danke.

Viele Grüße aus Magdeburg,
Tris.

1 Like

Wir planen das Servicepack im Moment für Januar 2023. Melden Sie sich gerne unter Bezug auf diesen Thread bei unserem Support, dann senden wir Ihnen ab morgen aktualisierte Module zu.

Hallo Herr Bartlau,

leider bin ich jetzt zum Testen der von ihnen bereitgestellten DLLs gekommen. Leider konnte ich damit nicht das gewünschte Verhalten nachvollziehen, d.h. es geht immer noch nicht. Vielleicht habe ich die falschen DLLs bekommen?

Der Code bei der Initialisierung:

...
InitializeComponent();
listLabelPreviewControl1.FileName = @"C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\Welcome.pdf";
...

Debwin bei der Ausführung der Zeilen:

Sie sehen, er setzt noch immer die Dateiendung auf *.LL.

Ersetzt habe ich einmal die cxLL28.dll (Originalversion 28.0.2022.29117) mit der von ihnen bereitgestellten 28.1.2022.31209.
Und die cmLL28.dll (Originalversion 28.0.2022.29117) mit der von ihnen bereitgestellten 28.1.2022.31208.
Beide bereitgestellten DLLs wurden in die jeweiligen Verzeichnisse für x64 bzw. x86 in C:\Program Files (x86)\combit\LL28\Redistribution kopiert. Auch ein Neustart des Rechners wurde vorgenommen.

Das verwendete PreviewControl in der .net-Applikation ist laut resx:

<data name="&gt;&gt;listLabelPreviewControl1.Type" xml:space="preserve">
    <value>combit.Reporting.ListLabelPreviewControl, combit.ListLabel28, Version=28.0.8322.28237, Culture=neutral, PublicKeyToken=a7a30592cb4a94be</value>
  </data>

Nun frage ich mich, ob ich die richtigen DLLs bekommen habe? Oder erscheint in Kürze das neue Servicepack. Das müsste ja auch die korrekte Implementierung haben, oder?

Vielen Dank für ihre Bemühungen,
Tris.

Hallo,

es ist natürlich schade zu hören, dass das Verhalten weiterhin reproduzierbar ist. In der Tat ist aber das kommende Service Pack für die Version 28 gerade in der Mache und wird für die kommenden Tage offiziell erwartet. Tatsächlich würde ich es nun so machen, dass wir Ihnen wie zuvor nochmal den aktuellen Modulstand dafür zur Verfügung stellen - gehabt über die Support-Case dazu. Sie sollten also in den nächsten Minuten einen Satz frischer DLLs haben.

Die Einbindung der neu von ihnen bereitgestellten DLLs hat geklappt und den gewünschten Effekt erzielt. Vielen Dank nochmal für ihre Bemühungen. :+1:

Liebe Grüße,
Tris.

Prima, nichts anderes wollte ich hören. Schön, wenn es nun endlich wie gedacht funktioniert und besten Dank für die Rückmeldung.