egon schrieb:
"Shared Events" in bestimmten Zusammenhängen die Gefahr von MemoryLeaks bergen. Worauf muss ich achten um mir nicht neue Probleme anzulachen?
Ist der Event-Konsument kurzlebiger als der Event-Sender, so kann der Garbage-Collector ersteren erst aufräumen, wenn das Event de-abonniert ist.
Weil der GC räumt alles auf, was per Code nicht mehr erreicht werden kann. Ein Event-Sender erreicht aber noch seine Abonnenten, was sie GC-Tabu macht.
Ein Shared Event "lebt" die komplette Programm-Laufzeit, und jeder der es abonniert ist solange GC-Tabu.
Wenn also zB. ein Form ein Shared Event abonniert und nicht deabonniert, so verbleibt es auch nach Schliessen im Speicher.
Mach das Form 50 mal auf und zu, dann kann sich das allmählich zu einem Problem auswachsen.
Lösung: Wird das Form (oder ein sonstiger Event-Empfänger) nicht mehr benötigt, so muss es unbedingt das shared Event de-abonnieren.
Ist kein großer Act - man musses nur wissen, und dran denken.
Wie gesagt: "in bestimmten Zusammenhängen" - weil wenn das Shared Event nur 2 o. 3 mal abonniert wird, dann ists nur unsauberer Stil, es nicht zu de-abonnieren, wird sich aber nicht merklich auswirken.
Nochmal wie gesagt: Das Problem tritt nur auf, wenn der Event-Sender länger lebt als sein Konsument.
Also normal haste zB einen Button auffm Form, der sein Click-Event ans Form sendet. Schliesste jetzt das Form, dann ist der Button weg, und das Form weg, und dann braucht man sich nicht um De-Abonnieren zu kümmern, weil dann sind beide code-unerreichbar, und dann räumt der GC auch beide auf.
Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von „ErfinderDesRades“ ()