ich bin gerade bei der Umstellung meines WPF Programms auf async (Daten via REST api holen) und gehe alle Komponenten durch.
Dabei würde ich gern erfahren, was die best practice für die Verwendung von LL ist:
Es gibt viele LL Berichte, die auch hintereinander mit unterschiedlichen Datasets und Variablen aufgerufen werden
Die Berichte werden von einem DI (Prism lib) erzeugt
In der Programmierer Referenz steht: “Aus Performancegründen empfiehlt es sich aber auch bei dynamischer Erzeugung, immer eine Instanz des ListLabel-Objektes global im Speicher zu halten”
Mein derzeitiger Zugang:
a) Berichte mit using() nach der Verwendung gleich wieder disposen
b) Ein LL Object beim Starten erzeugen, damit die Libs vorhanden sind
Mein derzeitiger Zugang:
a) Berichte mit using() nach der Verwendung gleich wieder disposen
b) Ein LL Object beim Starten erzeugen, damit die Libs vorhanden sind
… hierzu schon ziemlich gut passt, um die Laden-Performance von LL zu optimieren etc. Da wird bei combit auch immer die Geschichte mit dem Schutzjob genannt.
Vereinfacht ausgedrückt würde man in der Applikation global ein LL-Objekt erstellen, dass nichts weiter tut als da zu sein um beim Beenden sauber manuell disposed/freigegeben wird.
Und alle weiteren Aktionen rund um das LL-Reporting wie Designen, Drucken oder Exportieren erstellen dann immer ein eigenständiges LL-Objekt dazu - wenn technisch möglich gerne über das using()-Statement, da das LL-Objekt IDisposable implementiert hat und LL.Dispose() automatisch aufgerufen wird, wenn der using()-Scope verlassen wird.
ppreuschoff
(combit Support - Patrick Preuschoff)
3
Solange zusätzlich der ganze Code innerhalb des usings im gleichen Thread bleibt und die Objekte nur in diesem Thread verwendet werden hat man da eine sehr schicke Lösung
Bedenken müsste man aber noch, dass Interaktion mit UI-Elementen (z.B. eine Progress-Bar) dennoch in den Hauptthread synchronisiert werden müsste - aber das ist dann sicherlich auch keine Hürde mehr
kurze follow up Frage: Wenn ich den Schutzjob beim Schließen des Programms dispose, sollte dann nicht gleich das Modul Combit.ListLabel.dll entladen werden?
Was sind eigentlich die Folgen, wenn der Schutzjob nicht disposed wird?
Und wo kann man das sehen?
Danke
Niko
ppreuschoff
(combit Support - Patrick Preuschoff)
5
Beim “Disposen” wird der GarbageCollector darüber informiert, dass das entsprechende Objekt aus dem Arbeitsspeicher freigegeben werden kann - wann dies passiert ist aber in der Regel eine “Entscheidung” des GarbageCollectors.
Aus Sicht von List & Label werden zu diesem Zeitpunkt zusätzlich weitere Ressourcen freigegeben (weitere geladene List & Label-Module, etwaige vom System bereitgestellte Ressourcen, wie z.B. das RichEdit-Control, globale Handles und Referenzen auf Drucker(treiber)).
Wenn die ausgeführte Anwendung gänzlich aus dem Speicher entfernt wird, weil Sie beendet wird, kann ggf. der Arbeitsspeicher fragmentiert werden - wobei hier das .NET Framework eigentlich gut entgegenwirkt. Externe native Ressourcen, wie z.B. Handles, können weiterhin im System referenziert bleiben und erst nach einer gewissen Zeit in bestimmte Systemlimits laufen (und so Auffälligkeiten entwickeln). Unsere Entwicklungsabteilung empfiehlt daher bei selbst erstellten Objekten/Referenzen/Ressourcen ein sauberes Aufräumen.
Braucht ein Export eines Reports einen UI Thread oder kann das jeder beliebige Thread sein?
Nein, für das Erstellen der Exports kann auch ein Background-Thread verwendet werden - es muss nicht der UI-Thread sein. Kommt sonst noch darauf an, wie der Haupt-Thread (UI) über den Fortschritt des Exports im Hintergrund-Thread informiert werden soll… das müsste man sonst ggf. noch synchronisieren, damit der Anwender später weiß, dass da was passiert - sofern erforderlich.
einen Nachtrag habe ich noch: Ich gehe davon aus, dass die Vorschau eines Reports zum Ausdrucken auf jeden Fall im UI Thread erfolgen muss. Alles andere wäre sehr überraschend.
Heißt das auch, dass die async Abfragen von Daten (z.B. via SQL oder REST api) dann zum UI Thread zurückkehren muss?
