[Nicht lösbar] RDLC - Seitenansicht und Drucklayout

Hallo an Alle, insbesondere an Natalie,

Du hattest mal folgendes hier gepostet...

Problem: Seitenvorschau im RTC ist unpräzise.
- Seitenumbrüche fehlen, dadurch stimmt die Gesamtseitenzahl nicht
- Der Seitenrand wird nicht angezeigt
- Es werden Dinge an anderen Stellen platziert, als sie tatsächlich gedruckt werden.

Hintergrund: Die Seitenvorschau ist nur ein grobes Hilfsmittel. Aussagekraft hat nur das Drucklayout.
Nachzulesen (mit Screeshot): viewtopic.php?f=40&t=10116

Problem: In der Vorschau erscheint das Drucklayout-Symbol nicht
Grund: viewtopic.php?p=47025#p47025
Für Testzwecke ist es möglich, alle vorhandenen CurrReport.PREVIEWs im C/AL-Code vorübergehend auszukommentieren und so das Drucklayout-Symbol wieder erscheinen zu lassen. Für den Produktivbetrieb ist dies jedoch nicht möglich! Lässt man CurrReport.PREVIEW auskommentiert, würde nun bei jeder Seitenansicht "Anzahl gedruckt" im Belegkopf hochgezählt, der Beleg archiviert und ein Aktivitätsprotokollposten geschrieben werden.

... und genau das Problem hab ich nun auch. Für Testzwecke bei der Umstellung der NAV2009 CC RDL-Reports auf NAV2009 RTC RDLC-Reports kann ich ja CurrReport.PREVIEW auskommentieren aber im Echtbetrieb kann das ja nicht die Lösung sein aber auf die Buttons in der Seitenansicht will der Anwender ja wohl auch nicht verzichten. Gibt es dazu eine Lösung oder ein HotFix? Für NAV2013 gibt es den Fix aber für NAV2009 habe ich keinen gefunden.

Gibt es alternativ vielleicht einen Workaround? Weiß vielleicht jemand wie man im Code an die Buttons der Requestform herankommt? Dann könnte ich dort eine eigen Variable schalten wenn auf den Button "Seitenansicht" geklickt wird.

Ich verzweifle noch an all diesen Rückschritten...

Vielen Dank für Eure Hilfe im Voraus!

Grüße,
Uwe.

Zuletzt geändert von WNTS-UK am 6. Februar 2014 10:34, insgesamt 1-mal geändert.

Leider verstehe ich dein Problem noch nicht. Du möchtest unbedingt den Drucklayoutbutton haben?

Weiß vielleicht jemand wie man im Code an die Buttons der Requestform herankommt? Dann könnte ich dort eine eigen Variable schalten wenn auf den Button "Seitenansicht" geklickt wird.

Wenn ich dich richtig verstehe, brauchst du dann nur eine neue globale Variable, die du in die RequestPage, parallel zu den bereits vorhandenen, einbettest.

Hi Natalie,

ja, ich möchte, dass dem Anwender alle Buttons (Drucken, Drucklyout, Seite einrichten und Speichern als) zur Verfügung stehen. Dafür sind die Features doch da oder nicht!?
Aber wenn im CC irgendwo auf CurrReport.PREVIEW abgefragt wird, was bei uns bei fast jedem Report so ist, weil damit Daten-Updates gesteuert werden, sind die Buttons ja seltsamerweise nicht mehr sichtbar...

Offensichtlich handelt es sich dabei um einen Bug aber es gibt wohl nur für NAV2013 einen entsprechenden HotFix, wie der Nachfolgende Link zeigt:
http://dynamicsuser.net/forums/t/62386.aspx

Deshalb dachte ich, wenn man auf das Klick-Ereignis der Schaltfläche "Seitenansicht" der RequestForm reagieren könnte, könnte man dort eine globale, boolsche Variable schalten und anstatt auf CurrReport.PREVIEW, auf diese Variable (z.B. IsPreview) abfragen. Somit wäre das Problem gelöst. Aber anscheinend geht das wohl auch nicht. Zumindest wüsste ich keinen Trigger zu dem Button. Und deshalb die Frage an Euch ob ich überhaupt auf das Klickereignis des Buttons reagieren kann?

Gruß,
Uwe.

Offensichtlich handelt es sich dabei um einen Bug aber es gibt wohl nur für NAV2013 einen entsprechenden HotFix, wie der Nachfolgende Link zeigt:

Tatsächlich verhält es sich genau umgekehrt: Als NAV 2013 veröffentlicht wurde, hatte es einen Bug, der dafür sorgte, dass das Symbol sichtbar bleibt. Mit einem späteren Client-Update für 2013 verhielt sich der Report dann wieder so, wie du es von 2009 kennst.

Ein Fehler ist es deswegen, weil ein Report, sobald er sich bereits in der Vorschau befindet, nicht mehr von NAV kontrolliert wird: NAV weiß nicht mehr, ob der Report wirklich gedruckt oder doch nur betrachtet wird. Dass muss NAV aber wissen, weil es nur beim echten Ausdruck den Zähler bei "Anzahl gedruckt" hochsetzen darf. Nur als Beispiel.

Also heißt das dann, es gibt weder einen Fix noch einen Workaround für dieses Problem in NAV2009?

Bilder zum Szenario

Das ist doch auch im CC schon so, dass man den Druckbutton nicht mehr benutzen kann, wenn irgendwo CurrReport.PREVIEW im Report steht. Nur ist er da nicht ausgeblendet, sondern es kommt eine Fehlermeldung, wenn aus der Seitenansicht dann ausgedruckt werden soll.
http://msdn.microsoft.com/en-us/library/dd301398.aspx

Hallo Kai,

ja, das ist ja auch alles richtig. Aber es kann doch nicht sein, dass wenn ich keine Abfrage wie z.B.

Code:

IF NOT CurrReport.PREVIEW THEN

im Code verwende, das dann die Icons im RDLC angezeigt werden und funktionieren.
Diese Icons und ihre Funktionalitäten (insbesondere das Drucklayout und Speichern als) sind doch nützlich und sinnvoll. Vor allem kann man sich über das Drucklayout vor dem Druck vergewissern ob der Druck auch ok ist (Seitenumbrüche etc.).
Andererseits braucht man aber die Abfrage um Daten-Updates steuern zu können. Es muss doch möglich sein beides zu haben!? Ansonsten ist doch die Seitenansicht im RDLC völlig unnütz...

Gruß,
Uwe.

Vor allem kann man sich über das Drucklayout vor dem Druck vergewissern ob der Druck auch ok ist (Seitenumbrüche etc.).

Das geht im RDLC leider ohnehin nicht mehr, die Vorschau wird immer nur grob (dafür aber schneller) gerendert (erst ab NAV 2013 R2 kann man das nach Bedarf einstellen) , dadurch weicht das Layout im Detail vielfach zum Ergebnis beim Ausdruck ab. Wenn man das ohne Papierverschwendung kontrollieren will, immer als PDF "drucken". Alles andere führt zu bösen Überraschungen, wenn dann erst der Endanwender richtig druckt.

Doch natürlich geht es im RDLC, das ist doch das was ich bemängele.
Wenn im Code KEINE Abfrage auf CurrReport.PREVIEW steht, wird das Drucklayout-Icon angeboten und man kann sich anzeigen lassen, wie tatsächliche Druck ausschaut.

Aber anscheinend kann man nicht beides haben, Abfrage wegen Update-Steuerung und Icons in der Seitenvorschau. Nur wieso das so ist, ist mir völlig schleierhaft und es ergibt auch absolut keinen Sinn.

Also RDLC-Reports in NAV2009 sind der absolute Albtraum und stellen einen Rückschritt gegenüber den RDL-Reports dar!

Es ist genau so gewollt, im Verhalten identisch zum Classic Reporting. Wenn es sich um eine Voransicht handelt, dann darf auch nicht (mehrfach) gedruckt werden, da sonst die "Anzahl gedruckt" nicht aktualisiert wird oder auch Aktivitäten geschrieben würden. Wurde oben schon korrekt erwähnt.

Mal im Vergleich:

Hier möglich: Blättern durch Seiten, erste/letzte Seite, Anpassung Zoom, Anpassung Anzeige.
Nicht möglich: Drucken, Speichern, Seite einrichten.

ClassicReport.jpg

Hier möglich: Blättern durch Seiten, erste/letzte Seite, Anpassung Zoom, Suchen.
Nicht möglich: Drucken, Speichern, Seite einrichten.

RDLCReport.jpg

Was ist jetzt der Unterschied, abgesehen vom Drucklayout, welches nicht direkt angezeigt werden kann unter 2009, aber in 2013 R2 vorhanden ist und auch für 2013 per Hotfix nachgeliefert wurde?

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Hallo SilverX,

Was ist jetzt der Unterschied, abgesehen vom Drucklayout, welches nicht direkt angezeigt werden kann unter 2009, aber in 2013 R2 vorhanden ist und auch für 2013 per Hotfix nachgeliefert wurde?

wie gesagt, alles soweit richtig, bis eben auf die Tatsache, dass in 2009 kein Drucklayout angezeigt werden kann. Warum gibt es denn kein HotFix für 2009 diesbezgl.???
Und nochmal, wenn ich die Abfrage auf CurrReport.PREVIEW im Code auskommentiere und im RTC trotzdem die Vorschau aufrufe, dann werden die Icons angeboten und ich könnte aus der
Seitenansicht drucken so viel ich möchte und auch als PDF speichern etc.
Es geht mir aber grundsätzlich darum, dass die Seitenansicht im RTC/RDLC nicht das eigentliche Drucklayout wiederspiegelt, was die Seitenansicht im CC/RDL sehr wohl macht. Und der Endanwender also erstmal umständlich über einen "PDF-Drucker" drucken muss um sich das Druckergebnis, welches auf einem Drucker rauskommen würde anzeigen zu lassen. Das finde ich einfach steinzeitlich...

Grüße,
Uwe.

Wenn im Code KEINE Abfrage auf CurrReport.PREVIEW steht, wird das Drucklayout-Icon angeboten und man kann sich anzeigen lassen, wie tatsächliche Druck ausschaut.

Auch das Drucklayout ist je nach verwendeten Druckern und Komplexität des Reports unzuverlässig, das sind leidvolle Erfahrungen aus der Praxis in wochenlanger Fummelarbeit mit Reports, die dort einwandfrei aussahen, es dann aber doch nicht waren. Es wäre sicherlich sinnvoller, wenn zumindest der Button noch anboten werden würde (und auch die anderen nicht einfach verschwinden würden, sondern "not enabled" wären), aber von den Ergebnissen dort sollte man keine Rückschlüsse auf die Stimmigkeit des Ausdrucks ziehen.

Zum unterschiedlichen Renderingverhalten steht hier einiges: Understanding Rendering Behaviors

Der neue Vorschaumodus bietet sicherlich vieles neues z.B. interaktive Sortierung, aber einiges ist dabei auch auf der Strecke geblieben.

Hallo Uwe,

vielleicht an dieser Stelle nochmal einige zusätzliche Informationen, auch wenn damit das Drucklayout unter Dynamics NAV 2009 beim Preview trotzdem nicht angezeigt wird. Ich kenne die Komplexität, also den Grad des Unterschiedes zwischen 2009 und 2013, nicht, um dieses Feature zurück zu portieren. Vielleicht hat auch noch niemand mit einem deftigen Business Impact danach gefragt...

Die Anfrage des Rückgabewertes von CurrReport.PREVIEW fungiert seit Urzeiten als Schalter dafür, ob tatsächlich physikalisch gedruckt wird. Und damit auch für die Voransicht, das Drucken daraus zuzulassen oder nicht. Es ist Entwicklern vorbehalten darüber zu definieren, ob ein Report Funktionen beherbergt, die im Falle einer Voransicht nicht ausgeführt werden (dürfen).

Genau so im RDLC Reporting. Würde der ReportViewer bei Nutzung von CurrReport.PREVIEW direkt oder indirekt erlauben, aus der Voransicht auch auszudrucken, würde damit die vom Entwickler wissentlich implementierte Blockade unterlaufen, was natürlich nicht gewollt und ggf. auch rechtlich bedenklich ist.

Der ReportViewer ist eine externe Komponente - ein Control - aus Sicht von Dynamics NAV. Die zwei Produkte werden von unterschiedlichen Produktgruppen bei Microsoft betreut. Auf Dynamics NAV-Seite wird das Control nur in die Anwendung eingeblendet und die Features werden genutzt. Auf SQL Server-Seite ist die Voransicht, also die Interaktive Ansicht, aufgrund vieler dort vorhandener Features, das Mittel der Wahl.

Unter anderem bietet das ReportViewer-Control auch die Eigenschaft "ShowPrintButton". Diese allerdings, entfernt nicht nur den Druckerknopf, sondern auch Seiteneinrichtung und Druckansicht (siehe http://msdn.microsoft.com/en-US/library/vstudio/microsoft.reporting.winforms.reportviewer.showprintbutton(v=vs.110).aspx unter Remarks). Das gezielte Ausschalten des Druckersymbols ist nicht vorgesehen, sondern es betrifft alle direkt oder indirekt mit dem Druck zusammenhängende Symbole. Das ist auch der Grund, warum unter Dynamics NAV 2013+ die Eigenschaft in den Eigenschaften des Reports eingestellt werden kann/muss und nicht nachträglich in der Oberfläche umgeschaltet werden kann.

Zurück zum Entwickler: Dieser und nicht der Anwender, hat sich vom korrekten Layout des Berichts zu überzeugen. Ich denke nicht, dass ein Endanwender regelmäßig das Drucklayout auf Richtigkeit prüfen muss, ansonsten wäre bei der Entwicklung irgend etwas schief gelaufen. Im Allgemeinen ist "der Endanwender" interessiert an den Daten und Werten, beides ist in der interaktiven Ansicht gut zu sehen.

Bei Wechsel eines Druckers, um auch den Punkt von Kai kurz aufzugreifen, wird eh geprüft oder sollte zumindest geprüft werden, was hinten raus kommt und ob es korrekt ist. Aber auch das macht in den seltensten Fällen der Endanwender - jedes Mal...

Ich hoffe damit ein wenig Licht in das "Mysterium" gebracht zu haben. Schönen Abend euch!

Mein erster Gedanke als ich diesen Thread las war: "Stimmt, die Druckansicht wäre schön."
Aber bei einem fest gesteckten Formular braucht man es nicht. Wenn man dem Anwender eine Vorschau geben möchte, was das Layout anbetrifft, dann kann man einen zweiten Bericht erstellen und einbinden. Auf diesem kann ganz groß "Vorschau" stehen.

Aus meiner Erfahrung heraus weiß ich aber, dass im täglichen Geschäft nur die Daten wirklich wichtig sind, wenn der Bericht einmal entworfen ist.

...
Ich hoffe damit ein wenig Licht in das "Mysterium" gebracht zu haben. Schönen Abend euch!

Vielen Dank für die Information.

Hallo Carsten,

danke für die ausführlichen Infos!
Vielleicht bin ich auch einfach etwas zu anspruchsvoll, weil ich eben weiß was normalerweise machbar ist. Ich bin seit 1990 in der Softwareentwicklung und habe die verschiedensten Plattformen, Sprachen und Architekturen durchlebt. Die letzten ca. 12 Jahre habe ich mit Visual Studio, .Net und seinen Frameworks verbracht... Und nun...

Die Möglichkeit über die Show-Eigenschaften der einzelnen Buttons an das einblenden des DrucklayoutButtons zu kommen hatte ich mir auch schon angeschaut, musste aber leider auch erkennen, dass die Buttons nicht einzeln zu schalten sind
Aber dass ich mit meiner "Forderung" nicht falsch liege, sieht man ja dann doch an der Tatsache, dass man in NAV2013 die Möglichkeit zum einstellen hat...
Ich frage mich nur warum man diese Möglichkeit nicht auch für 2009 RTC nachgezogen hat!?

Naja, wie auch immer, es fällt wirklich schwer sich mit etwas abfinden zu müssen obwohl man weiß, dass es möglich ist

Trotzdem danke an alle für Eure Antworten und Eure Mühe!

Gruß,
Uwe.

Hallo Carsten,

Unter anderem bietet das ReportViewer-Control auch die Eigenschaft "ShowPrintButton". Diese allerdings, entfernt nicht nur den Druckerknopf, sondern auch Seiteneinrichtung und Druckansicht (siehe http://msdn.microsoft.com/en-US/library/vstudio/microsoft.reporting.winforms.reportviewer.showprintbutton(v=vs.110).aspx unter Remarks).

Eine Frage habe ich nun rein interessehalber dazu doch noch.
Komme ich denn im Code des RDLC-Reports überhaupt ohne externe Assembly an die Show-Eigenschaften der Buttons in der Symbolleiste des ReportViewer-Controls?
Es stehen ja nur die Namespaces "Microsoft.VisaulBasic" und "Microsoft.Win32" zur Verfügung. Benötigt wird aber "Microsoft.Reporting.WinForms". Und mit dem Schlüsselwort "Me", also "Me.ShowPrintButton = True" gehts ja auch nicht. Hab ich da was übersehen oder denke ich zu kompliziert oder geht es nicht ohne externe Assembly?

LG,
Uwe.

Hallo Uwe,

natürlich kann man auf die Eigenschaften nicht von außen zugreifen. Auch wenn meine Erläuterung das eventuell vermuten lässt, wollte ich nur darstellen, dass diese 3 Knöpfe zusammengehören.
Das ReportViewer-Control wird im Client selbst aufgerufen, kann also von außen nicht (nachträglich) beeinflusst werden.

Ahhh, ok. Also gibt es keine Möglichkeit.. Schade.
Trotzdem Danke für die Bestätigung!

Gruß,
Uwe.