Laden...

[gelöst] Problem mit mehreren Instanzen einer Klasse

Erstellt von blutiger_anfänger vor 15 Jahren Letzter Beitrag vor 15 Jahren 824 Views
B
blutiger_anfänger Themenstarter:in
293 Beiträge seit 2008
vor 15 Jahren
[gelöst] Problem mit mehreren Instanzen einer Klasse

Hallo liebe CSharpler,
ich stehe mal wieder auf dem Schlauch.
Ich habe mir eine Klasse gebastelt, die mir Videos herunterladen und konvertieren kann.
Der aktuelle Status des Downloads/der Kovertierung wird in einem String in der Klasse abgelegt, den ich mit Hilfe eines Timers im Sekundentakt einlese und dann damit einige Controls mit den Infos befülle.

Doch nun zu meinem eigentlichen Problem. Wenn ich die Klasse einmal Instanziere und dann zwei Downloads starte, dann haut das mit dem Status nicht mehr hin, weil der Statusstring andauernd wechselseitig überschrieben wird.

Also habe ich die Klasse nun erst beim Button-Click instanziert. Jetzt weiß ich jedoch nicht mehr wie ich mit meinem Timer auf die aktuelle Instanz bzw. alle Instanzen zugreifen kann, da der TimerTick-Eventhandler ja garnicht von der Klasse weiß, da diese ja im ButtonOnclick instanziert wurde.

Ich hatte auch schon überlegt, den Timer im ButtonOnclick zu instanzieren und dann im Tickevent erst die Klasse zu instanzieren, aber ich weiß nicht wie ich dann, wenn der Download Fertig ist, den Timer wieder stoppen kann, da ja dann der Timer im ButtonOnclick instanziert wurde und ich dann außerhalb des ButtonOnClick-Events den Timer nicht mehr "kenne", sprich ihn auch nicht mehr ála timer.Stop(); anhalten kann.

Ich hoffe ihr könnt mir einigermaßen folgen und mir einen Anstoß geben, wie ich das Problem lösen kann.

liebe Grüße,
Raffi

Wenn ich nicht hier bin, findest du mich auf code-bude.net.

M
125 Beiträge seit 2008
vor 15 Jahren

Du brauchst doch nur die Klasse außerhalb der ButtonClick-Methode deklarieren und schon kannst du ständig drauf zu greifen.

// Edit
Oder du benutzt das Singelton Pattern, damit kannst du IMMER drauf zugreifen!

B
blutiger_anfänger Themenstarter:in
293 Beiträge seit 2008
vor 15 Jahren

Ich weiß, dass ich sie außerhalb deklarien kann, aber dann funktioniert die Reportgeschichte nicht mehr.

In meiner Klasse gibt es einen string Namens DownloadState. Wenn ich die Funktion DownloadVideo(); aufrufe, dann schreibt diese den aktuellen Downloadstatus in den String DownloadState.

Diesen String lese ich mit dem schon erwähnten Timer aus und aktualiere dann das UI (Progressbar, Label, ...).
Wenn ich die Klasse außerhalb des OnClick deklariere und dann 2 Downloads parallel laufen lasse, dann schreiben beide in den DownloadState String, was zur folge hat, dass mein Timer nurnoch Schrott einließt. Deshalb hatte ich die Klasse ja erst im OnClick deklariert...

Danke dir trotzdem schonmal!

Wenn ich nicht hier bin, findest du mich auf code-bude.net.

M
125 Beiträge seit 2008
vor 15 Jahren

OK ich verstehe, was du meinst.

Anderer Vorschlag:
du könntest deine Instanzen auch in einer Liste speichern..

B
blutiger_anfänger Themenstarter:in
293 Beiträge seit 2008
vor 15 Jahren

Das mit der Liste hat super geklappt!
Ich muss mir das mit den Listen nochmal ernsthaft einbleuen. Das war letztens auch schon die Lösung eines anderen Problems. (Aber das ist hier wohl eher OT.)

Danke nochmal und einen schönen Montag-Restabend 😉

Liebe Grüße,
ein blutiger_anfänger

Wenn ich nicht hier bin, findest du mich auf code-bude.net.

C
252 Beiträge seit 2007
vor 15 Jahren

Ich würde das grundsätzlich anders lösen. Und zwar nicht jedes mal die Klasse danach fragen wie der Status ist, sondern die Klasse "sagt selbst"(also feuert ein Event) wenn es einen neuen Status gibt bzw der sich geändert hat.
So kommst du vom Polling weg.

M
125 Beiträge seit 2008
vor 15 Jahren

Stichwort Observer Pattern

3.971 Beiträge seit 2006
vor 15 Jahren

Das Observer-Pattern braucht man sogut wie garnicht in .NET, da dies bereits vollständig durch Events und Delegaten abgedeckt wird.

[FAQ] Eigenen Event definieren / Information zu Events

Es gibt 3 Arten von Menschen, die die bis 3 zählen können und die, die es nicht können...