bin immer noch neu in List & Label, beziehungsweise in der Evaluierungsphase ob ich LL für spätere Entwicklungen einsetzten kann.
Derzeit würde ich gerne ausprobieren wie man Grafikobjekte / Diagramme welche nicht mit der Chart Funktionalität von LL erstellt worden sind, in einen LL Report einbinden kann.
Im konkreten Fall geht es um ein TeeChart (Steema) welches zur Laufzeit generiert wird. Wie könnte ich das in einen LL Report einbinden?
Hat jemand Erfahrung damit, oder kann mir einen Hinweis geben, welche Möglichkeiten man in List & Label diesbezüglich hat.
In .NET sollte es kein Thema sein. Aber auch oohn das kannst Du natürlich diesen Chart immer auch als Bild (oder EMF) übergeben, aber in .NET geht es halt auch als Vektorgrafik “direkt in den Druck-DC”.
Beim Einbinden in anderen Report Softwaren hatten wir oft das Problem das die Bilder oft sehr groß geworden sind beim Exportieren. Hat damit etwas zu tun das es ein Chart war welcher eine ganze DINA 4 Seite eingenommen hat und man die DPI Zahl hoch setzten musste damit auf dem Bild dann auch noch etwas zu erkennen war. Beim exportieren ins PDF hat sich dann ein File mit mehreren MB ergeben. Da wurden beim PDF generieren keine Optimierungen mehr gemacht. Da bin ich mal gespannt wie gut da LL ist.
Beim export / import als EMF muss die Vektorgrafik dann auch richtig interpretiert werden. Active Reports hat da definitiv Probleme. Da hat das Chart nicht mehr gleich ausgesehen. Jetzt bin ich auf der Suche wie ich das in LL machen / bzw. überprüfen kann.
Immer noch froh um jeden Hinweis. Danke schon mal bis hierher.
a) Erzeuge ein EMF und übergib das an LL
Vorteile:
- unabhängig von der Entwicklungsumgebung, vom LL-Core unterstützt
- (relativ) beliebig skalierbar
- oft kleiner Speicherverbrauch
Nachteile:
- nicht alle EMFs, die Komponenten erzeugen, sind auch korrekte EMFs (habe da meine Erfahrungen gemacht mit einem EMF-Konverterversuch...)
- nicht alle Komponenten können EMFs erzeugen
b) Erzeuge eine Bitmap und übergib diese.
Vorteile:
- unabhängig von der Entwicklungsumgebung, vom LL-Core unterstützt
- alle Komponenten könen das (wenn nicht -> Komponente nix wert, NULL-Device)
- beliebig skalierbar per DPI-Zahl (wenn nicht -> Komponente nix wert, NULL-Device)
Nachteile:
- relativ groß (JPG, PNG, TIF etc. von Vorteil, aber dann müssen sie an LL per Dateipfad übergeben werden)
c) Man definiert ein "Benutzerobjekt" (LL_DRAWING_USEROBJ-Variable/Feld) und läßt die Komponente in das im Callback übergebene Device malen
Vorteile:
- unabhängig von der Entwicklungsumgebung, im LL-Core
- kann auch einen Konfigurationsdialog haben (LL_DRAWING_USEROBJ_DLG)
Nachteile:
- nicht ganz intuitiv (Callback oder Nachrichtenunterstützung nötig im Host)
- nicht alle Komponenten kommen mit einem beliebigen Device aus (wenn nicht -> Komponente nix wert, NULL-Device)
d) Man benutzt ein "Designer-Objekt" und unterstützt ein paar Events
Vorteile:
- relativ einfach (in der Skalierung steckt manchmal die Tücke, probieren!)
- mächtig (man hat sogar die Möglichkeit, Properties in die LL-Properties einzubinden)
- Beispielcode vorhanden ("Designer Extension Sample", "TX Text Control Designer Object", und ganz nett "Designer Property Sample")
Nachteile:
- nur in C# (evtl noch Pascal/Delphi/Embarcadero/RAD Studio/... wie immer das Teil heute wieder heißt...)
- nicht alle Komponenten kommen mit einem beliebigen Device aus (wenn nicht -> Komponente nix wert, NULL-Device)
