Reporting-Software für Visual C#

    Liebe Leute,


    welche Reporting-Software für Visual C# kennt ihr? Wir benötigen Berichte, die direkt in unsere Anwendung eingebunden werden (nicht als separates Programm), und die Berichte sollten Matrixtabellen (manchmal auch Tablix oder Kreuztabellen genannt) sowie mehrere Tabellen im selben Bericht enthalten, mit dynamisch wachsender Größe und wechselnder Position.


    Wir haben bisher SAP Crystal Reports in unserer Anwendung verwendet, aber es hat einige Nachteile, wie z.B.: es muss separat installiert werden, anstatt zusammen mit der Anwendung als Satz von DLL-Dateien installiert zu werden; außerdem macht der Designer manchmal Probleme und wir haben nicht immer die Möglichkeit, neue Datensätze korrekt hinzuzufügen.


    Wir haben bisher die folgenden Alternativen ausprobiert: MS Reports, FastReport.Net, DevExpress, List & Label, ActiveReports, Stimulsoft. Alle diese weisen gewisse Probleme auf, weswegen wir sie nicht verwenden können bzw. nicht verwenden wollen.


    Falls jemand von euch Erfahrungen mit entsprechender Software haben und uns einen Tipp geben können sollte, sind wir sehr dankbar.

    Ist es notwendig das der Anwender der Software, die Ausgaben nachträglich ändern kann oder handelt es sich nur um

    "Ausgaben" die angezeigt werden um diese dann (z.Bsp.) zu drucken?


    Wenn der Anwender keine Veränderungen mehr an den Ausgaben vornehmen muß/soll, bietet sich die Möglichkeit an,

    die Ausgabe intern als HTML in einem String zu erstellen und anschließend via dem WebBrowser-Control anzuzeigen bzw. auszudrucken. Diese Technik verwendete ich bei einem Geschäftsprogramm und sie funktioniert recht gut.

    Allerdings nehme ich an, daß Sie bereits selbst auf diesen Ansatz gekommen sind.


    Mit den oben erwähnten Reporting-Tools habe ich keine Erfahrung, jedoch mit der Erstellung von interaktiven

    Grafik/Drawing-Applikationen. Ein Reporting-Tool ist "im Prinzip" eine Art angepaßte/spezielle Drawing-Applikation.


    Wie komplex ist ist die Interaktion, welche der Anwender ausführen können soll?

    Wenn es sich lediglich um ein paar Funktionen handelt, ist es fraglich ob es nicht besser wäre ein solches vereinfachtes Reporting-Tool selbst zu entwickeln. Um dies zu beurteilen wären aber mehr Hintergundinformationen über die Funktionsvielfalt des Moduls erforderlich.


    Ist es notwenig das der Anwender die Ausgaben "graphisch" ändern kann oder wäre auch eine textuelle Lösung in Form einer angepaßten Script-Sprache möglich? Das heißt, der User erstellt eine Art "Script" (als Vorlage) welches anschließend interpretiert und gerendert wird. Solche Vorlagen ließen sich speichern und wiederverwenden, ähnlich wie Form-Briefe.

    Ist natürlich für den Anweder gewöhnungsbedürftig, auf der anderen Seite ließen sich damit recht komplexe Ausgaben, u.a. mit enthaltenen Berechnungen, realisieren.


    Den Ansatz, einen "Editor" als Reporting-Tool zu verwenden haben Sie sicher schon versucht. Wenn Sie hierbei auf das RichTextBox-Control zurückgreifen, quälen Sie sich eher früher als später, mit der Komplexität der Win32-API herum, was nicht nur recht frustrierend sondern vor allem Zeitrauben ist.


    Leider fallen mir im Moment keine weiteren brauchbaren Alternativen ein, Sorry.


    Weitere Hintergrundinformationen wären aber hilfreich.

    Lieber pivique, vielen Dank für Ihre Antwort.


    Der Benutzer muss die Ausgabe nicht ändern können. Die Möglichkeit mit HTML-Browser bestünde also.


    Eine Reporting Engine selbst zu entwickeln haben wir auch bereits angedacht, aber der Aufwand scheint uns zu groß zu sein.


    Die Ausgabe besteht nur aus Tabellen, Grafiken kommen nicht vor.


    Wir haben inzwischen die Erfahrung gemacht, dass es zwei Reporting Tools gibt, die eventuell geeignet wären (genau wissen wir es noch nicht - jedenfalls haben wir noch nichts gefunden, das sie disqualifizieren würde), aber die Einbindung in das Programm gestaltet sich mühsam bzw. ist mir bis jetzt nicht gelungen. Es scheint so zu sein, als müssten wir den Weg mit dem HTML-Browser gehen.

    Die Lösung mit dem HTML Viewer ist insofern problematisch, als es auch darum geht, die Reports auszudrucken. Beim Ausdrucken muss garantiert werden, dass Tabellen auf einer Seite zusammengehalten werden. Es darf auch nicht sein, dass zum Beispiel die Überschrift auf der einen Seite ausgedruckt wird und die eigentliche Tabelle auf der nächsten Seite. Wie sollten wir das erreichen? Haben Sie diesbezüglich Erfahrungswerte oder Lösungsideen?

    > Der Benutzer muss die Ausgabe nicht ändern können. Die Möglichkeit mit HTML-Browser bestünde also.


    Die Anforderung, das der Benutzer die Ausgabe nicht ändern können muß, vereinfacht das ganze Problem enorm. Damit wird das Reporting-Tool geradezu "trivial" (entschuldigen Sie bitte diese Redewendung).


    Die HTML-Lösung ist hierbei die einfachste, da HTML im Grunde Tabellen unterstützt und der Internet-Explorer, der dem WebBrowser-Control zugrunde liegt (zumindest in der Version 2.0...?), unterstützt diese recht gut (meiner Erfahrung nach).

    Das heißt, diverse Tags zur Ausrichtung der Tabelleneinträge, Hintergrundfarben und andere Eigenschaften lassen sich recht einfach festlegen. Sollten die üblichen HTML-Elemente nicht ausreichen kann man immer noch CSS-Code in die Seite einbinden, welche viel weitreichendere Möglichkeiten bietet.


    (Kleiner Hinweise, der eigentlich nicht erforderlich wäre: verwenden sie bei der HTML-generierung die Klasse StringBuilder)


    Das Problem mit dem "Seitenumbruch" (ich nenne, das jetzt einfach mal so), ließe sich auf zumindest zwei Weisen lösen. Erstens unterstützt HTML ein sogenanntes <nobr>-Tag, welches Elemente "zusammenbindet", ob das aber auch Seitenübergreifend funktioniert müßte man ausprobieren.


    Desweiteren bestünde die Möglichkeit, die Überschrift, direkt in die Tabelle einzubinden, als eigne Zeile sozusagen, oder zwei ineinander geschachtelte Tabellen zu erstellen (eine mit der Überschrift, die andere mit den Daten). HTML bietet hier wirklich viel Flexibilität, und es erfordert meistens nur ein wenig "Kreativität".


    Der Vorteil bei der HTML-Lösung ist, das sich der HTML-Code sehr einfach generieren läßt. Der Nachteil hingegen ist, das die Druckausgabe ein weniger umständlicer zu implementieren ist. Aber da dieses Modul sher schnell umgesetzt werden kann, sollte es auf alle Fälle mal ausprobiert werden. Ein paar Stunden für die Umsetztung sollten ausreichen (nach meiner Erfahrung).


    Eine andere Möglichkeit für das "Seitenumbruch"-Problem, wäre die "Größe" (Size) der Elemente (Tabellen, Text, etc.), welche gedruckt werden, im Voraus zu berechnen. Eine ungefähre "Schätzungs-Berechung" würde hierbei schon genügen und danach den generierten HTML-Text entsprechend anzupassen.


    Ein anderer Ansatz, wäre eine kleine Rendering-Engine auf Basis der System.Drawing-Klassen/Methoden zu entwickeln. Dies ist sehr einfach und ebenso in wenigen Stunden, oder ein-/zwei Tagen umzusetzen. (Hab ich bereits mehrmals gemacht). Damit lassen sich dann alle Ausdrucks-Elemente ganz exakt berechnen und plazieren (layouten).

    Das Ausdrucken ist dann normalerweise auch keine alzuschwierige Sache, nur sollte man dann weitere ein/zwei-Tage (oder mehr) für die Implementierung des Printing-Dialogs und die Benutzerführung berücksichtigen.


    Der erste Ansatz ist schneller umzusetzen, benötigt ein wenig mehr Speicher (Internet-Explorer im Hintergrund!) und die Druckausgabe erfordert mehr Aufmerksamkeit.


    Der zweite Ansatz erfordert ein wenig mehr Zeit, erlaubt aber jedes Detail und zukünftige Anforderunen detailiert umzusetzten. Grafiken sind beim zweiten Ansatz einfacher einzubinden, als bei der HTML-Lösung.

    Kleiner Nachtrag zu meiner vorherigen Antwort (ich mußte erst den Namen der folgend genannten Komponente in Erfahrung bringen!)


    Als Alternative zum WebBrowser-Control des NFW bietet sich natürlich auch an, einen anderen HTML-Renderer zu verwenden, wenn man sich für die "HTML"-Lösung entscheidet.


    Eines der alternativen Controls, welche ich mir näher ansehen würde nennt sich "HTML Renderer", zu finden unter "https://www.nuget.org/packages/HtmlRenderer.Core".


    Das Paket ist schon mehr als zehn Jahre alt (ich habe es mir zumindest vor rund 10 Jahren angehsehen) und ist lt. Beschreibung "100% managed Code", was schon mal gut ist. Das wesentliche aber für das "Seitenumbruch"-Problem ist, das sich die Größe (Size) der HTML-Elemente über eine bestimmte Methode bestimmen läßt. (Ich glaube die Methode nennt sich "MeasureBounds").


    Bei codeproject findet sich ein einführender Artikel unter "A Professional HTML Renderer You Will Use", zu finden unter "https://www.codeproject.com/Articles/32376/A-Professional-HTML-Renderer-You-Will-Use".

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden