> 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.
