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…er-You-Will-Use".

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

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.

Vielleicht könnten mir die besonders intelligenten Mitglieder von Prudentia die beiden folgenden Fragen beantworten:

a) Was ist Intelligenz?

b) Was mißt ein Intelligenz-Test eigentlich?

Bitte keine Definitionen aus wikipedia anführen.

Für ein kleines Geschäftsprogramm suchte ich nach einem Reporting-Modul welches nicht allzu komplex und "umfangreich" war. Ich stolperte dann über den Artikel "WPF-Less GDI+.NET Report Component: Star Report" (https://www.codeproject.com/Articles/51802…ent-Star-Report) und nach einigen Anpasungen und Erweiterungen erwies es sich als brauchbare Komponente - zumindest für meinen einfachen Anwendungsfall.

Ihr benötigt wahrscheinlich eine "Fix-und-Fertig-und-Kann-Alles"-Modul, womit ich jedoch keine Erfahrungen beisteurn kann. Aber vielleicht habt ihr ja auch nur eine ganz bestimmte Problemstellung zu lösen und könnt eine Halbfertige Lösung anpassen.

ad) "wegen seines großen Speicherverbrauchs aufgegeben"

Die GC (Garbage Collection) läßt sich auch "manuell" aufrufen. Normalerweise wird diese vom System automatisch ausgeführt und sollte es zu Problemen hierbei kommen stimmt irgendetwas nicht. Dieses Problem sollte näher untersucht werden, falls ihr euch für jenes Modul entscheidet!

ad) "weil es mühsam ist, dass der Benutzer die Crystal Reports DLL-Dateien herunterladen und installieren muss"

Die (externen) DLL's lassen sich auch DIREKT in die eigene exe-Datei der Apllikation einbinden! Somit muß der User keine

DLLs downloaden! Eine simple google-Suche sollte Artikel listen, die zeigen wie man sowas macht. Beim compilieren via Kommandozeile ist es recht einfach.

Allerdings bleibt die Frage offen ob man es aus rechtlicher Sicht darf die DLLs in die eigene exe-Datei einzubinden. Eine einfache Anfrage per Mail beim Hersteller des Moduls sollte diese Frage klären.

Folgende Artikel/Bücher sollten Ihnen weiterhelfen.
(Das finden der entsprechenden Links mittels google überlasse ich Ihnen.)

* Artikel "Aleksei Krassovskikh" "Advanced text editor with ruler"<BR>
* Artikel "Bernardo Castilho" "RichTextBoxDocument"<BR>
* Artikel "Scott Lysle" "Word Processing with an Extended Rich Text Box Control"
<BR><BR>
* Buch "Chris Sells, Michael Weinhardt/Windows Forms 2.0 Programming"<BR>
- Chapter 8, Printing<BR>
* Buch "Eric White/Pro .NET 2.0 Graphics Programming/Building Custom Controls using GDI+"
<BR><BR>
Es gibt auch eine Reihe von "fertigen" Editor-Controls zu kaufen,
was wahrscheinlich billiger wäre als diese selbst zu entwickelt.
Allerdings kann man diese Frage nicht allgemein beantworten,
denn diese hängt vom Kontext ab, in welchem die SW entwickelt
wird.
<BR><BR>
Ich habe mal (vor vielen Jahren) einige dieser kommerziellen
Wysiwyg-Edit-Controls untersucht, da ich ein solches für
mein SW-Projekt benötigte. Die meisten sind jedoch nicht brauchbar,
da zu "fett" (~ 50 Mb!) und andere widerum, bassieren auf dem
Internet-Explorer!
<BR><BR>
Ohne hier Werbung betreiben zu wollen, aber das Control von
"TE Edit" (http://www.texcontrol.com) schien mir noch eines der besseren
zu sein, auch wenn es ein Wrapper um eine Win32-Library war.
<BR><BR>
Wie die Dinge heute stehen kann ich leider nicht sagen.
<BR><BR>
Um genauers sagen zu können, benötigt man im allg. mehr
Hintergrundinformationen zum Kontext der zu entwickelnden
Applikation (Anforderungen an die Software,
privat/kommerziell/Firmen-intern, etc.).
<BR><BR>
MfG
11.

Zitat von Adok

Eine Programm-Routine, die ein RTF-Dokument als Bitmap-Objekt rendert, wäre die ideale Lösung. Leider konnte ich so etwas mit Google nicht finden. Möglicherweise bleibt mir nichts übrig, als diese Routine selbst zu schreiben.

Es gibt im Netz eine ganze Reihe von Source Codes zu "Extended RichText Boxes", welche oft auch mit einer entsprechenden Druck-Funktion ausgestattet sind. Sie müßten den SrcCde entsprechend "analysieren". Auch bei MSDN findet man was, wenn man sucht. https://support.microsoft.com/en-us/help/811…ing-visual-basi Eine weitere Möglichkeit wäre, das RTF der RichTextBox nach HTML zu konvertieren und dann über das WebControl auszudrucken. Oder man schreibt mal auf die schnelle, selbst eine einfache PrintEngine - ist nicht allzu schwierig. Auch gibt es einige Bücher speziell zum Thema Windows.Forms. Ich habe vor fünf Jahren komplexere SW in Windows.Forms implementiert, und könnte ggfs. aushelfen, wenn nötig. MfG 11.