Aktuell kombinieren wir mehrere Reports für das PreviewControl, indem die Preview-Dateien der einzelnen Reports an einer Ergebnis-Preview-Datei angefügt wird. Diese wird letztendlich im Control dargestellt.
Da jedoch hierbei jede Menge zu beachten ist und dies in unserem Szenario auch einiges an Verwaltung erforderlich macht, wollen wir dieses Vorgehen nun durch den “Kombinationsdruck” ersetzen. Dieser Ansatz erscheint uns wesentlich robuster und einfacher.
Nach einer ersten Testumstellung gibt es jedoch Probleme, sobald IncrementalPreview=false gesetzt wird. Dann kommt es zu den unterschiedlichsten Effekten (leere Preview, nur der letzte Report wird dargestellt, eigene Variablenersetzung in RTFs wird nicht korrekt durchgeführt, teilweise Abstürze bzw. Meldung über fehlende LL-Datei).
Aktuell setzen wir die Report-spezifische Datenquelle, da sich diese teilweise vollständig voneinander unterscheiden, innerhalb des Events NextCombinationPrintStep.
Jetzt unsere Frage dazu:
Ist ein Wechsel der Datenquelle innerhalb NextCombinationPrintStep überhaupt definiert und der korrekte Weg? Welche Möglichkeit hätten wir andernfalls, um unterschiedliche Datenquellen im Kombinationsdruck pro Report zu verwenden?
Ja, der Event ist genau dafür gedacht. Insofern sollte das auch klappen. Wenn Sie uns ein Sample bereitstellen könnten, das das Problem reproduziert können wir uns das gerne ansehen .
Vielen Dank für die schnelle Reaktion. Wir haben uns unseren Code noch einmal genauer angeschaut und dabei festgestellt, dass wir die verwendeten List&Label-Objekte nach Nutzung nicht mehr korrekt per Dispose zerstört haben. Nachdem die Zerstörung per Dispose nun korrekt durchgeführt wird, traten keine größeren Probleme mehr auf.
Aktuell treten lediglich Probleme bei Nutzung von “IncrementalPreview = false” auf. In diesem Fall wird keine oder eine fehlerhafte Preview im PreviewControl dargestellt. Dieses Problem ist für uns allerdings im Moment nicht relevant, da die Eigenschaft “IncrementalPreview” in unserer eigenen Ableitung der List&Label-Klasse versteckt und damit nicht steuerbar ist.
Sollten weitere Probleme auftreten, so werden wir uns noch einmal melden
Als Nachtrag: wir konnten das Problem im Falle von IncrementalPreview auf false reproduzieren und haben dieses in der seit heute aktuellen Version 28 gelöst. Die Änderung wird nicht im Release 28.000 enthalten sein, sondern mit dem ersten Servicepack ausgeliefert. Wenn Sie den Fix doch noch benötigen sollten können Sie sich jederzeit gerne bei uns melden. Vielen Dank für den Hinweis !
