Hey,

den Zusammenhang von Timer und Backgroundworker ist mir bei dir noch nicht ganz klar. Vielleicht schaust du dir zunächst diesen Beitrag an: [Allgemein] muss es immer Timer sein?

Gruß Manschula

Um CPU und Ram-Auslastung abzufragen brauchst du nur einen Timer. Wozu die anderen?

Wenn die Einzelnen "Auslese-Vorgänge" (=> performanceCounter, Auslastungs-Abfrage & Auslesen der Festplattendaten) länger dauern, dann würde ich diese in einen BGW auslagern. Ein (!) Timer soll dann regelmäßig sagen, dass jetzt Daten aktualisiert werden sollen - sprich der/die BGW (einer sollte dafür aber auch reichen) beginnen ihre Arbeit. Ist der BGW fertig, dann feuert er das Complete-Event - ein Zeichen für dich, die GUI (also labels, die Combobox, etc) mit den neuen Daten zu füttern.

Edit: "Merkst" du, dass die Timer ausbremsen oder vermutest du das nur? Nenn auch mal das eingestellte Interval^^

Aber das kannst Du doch alles mit einem Timer steuern. Überdenk mal ein bisschen die Architektur Deines Programmes. Mit den Timern killst Du Dein Programm, das hast Du ja schon selber erkannt. Mach Dir doch für die einzelnen Abfragen extra Klassen. Statte jede Klasse mit einer Methode z. B. "GetValues()" oder so ähnlich aus und ruf im Hauptprogramm, beim Timer.Tick die Methoden auf. Probiers mal, es geht alles mit einem Timer, wenn es denn schon ein Timer sein muss.

Mal ernsthaft?
Timer um ne Combobox zu befüllen?

Dir ist schon klar, dass wenn nen halbwegs großes Projekten deinen Programmierstil verwenden würde, es wahrscheinlich 500-5000 Timer am laufen hätte?

Falls Du Dich dazu entscheidest, die Abfragen in eigene Klassen auszulagern, so wie ich es Dir vorgeschlagen habe, ist hier ein guter Zeitpunkt, um sich mit Interfaces zu befassen. Nur so als kleiner Tip.

wieso Interfaces?

eine gemeinsame Basisklasse für die verschiedenen Abfrage-Klassen scheint mir einfacher.
möglicherweise noch einfacher mag sein, einem Delegaten verschiedenartige Abfrage-Methoden zuzuweisen.

Aja, das ist ein seeeehr altes Tutorial von mir,
wie schon öfters gesagt, das kannst du alles auf einen Timer unschreiben.

Hallo

also, meiner Ansicht nach bieten sich Interfaces für dieses Problem an. Ich bin damals selbst an dem Problem mit den Timern gescheitert, als ich mir selbst eine kleine "Sidebar" erstellen wollte. Irgendwann kam dann der Moment, wo ich mich mehr mit Klassen und Interfaces beschäftigt habe. Eines Vorweg, ich behaupte nicht, dass ich alles zu 100% kapiere, aber ich glaube, dass der TE genau hier ein Stückchen weiter kommt. Also, ich hab Dir wie versprochen ein kleines Beispiel erstellt. Es gibt 3 Klassen: Eine Klasse liest den freien Festplattenspeicher aus, eine den freien Arbeitsspeicher, eine gibt einfach nur die Zeit aus. Das soll Dir verdeutlichen, wie man alles mit einem Timer unter die Haube bekommt. Es gibt sicher andere Möglichkeiten, aber das ist mein Vorschlag. Erst mal die 3 Klassen, die die Werte auslesen.







Wie Du in den Klassendefinitionen sehen kannst, implementieren alle 3 Klassen die Schnittstelle (Interface) "IReaderUpdate".



Eine Schnittstelle ist grundsätzlich nichts anderes, als die Vorgabe, was eine Klasse können muss. Und wie Du in den Klassen siehst haben alle 3 die Methode:



Damit hast Du die Möglichkeit, jede dieser 3 Klassen über eine "Schnittstellenvariable" aufzurufen. Das gibt Dir im Hauptprogramm den Vorteil, dass Du alle 3 Klassen in einer



zusammenfassen kannst. Der Code fürs Hauptprogramm sieht so aus.



Wie der ErfinderDesRades sagte, gibts hier auch die Möglichkeit, eine Basisklasse für alle "Reader" zu erstellen und die entsprechenden Reader von dieser Klasse erben zu lassen. Aber, da man hier nur eine Methode aufrufen muss, finde ich Interfaces eleganter. Es ist beides möglich und eine gemeinsame Basisklasse hat halt wieder andere Vorteile. Nur ich finde Interfaces einfacher zu verstehen.

Die Schnittstellenvariable ermöglicht es Dir, auf die in der Schnittstelle definierte Sub, zuzugreifen. Im Timer.Tick-Event rufst Du genau diese Sub dann auf.

also ich habe die Messwerte jetzt als Datensatz aufgefasst, dem ich auch eine Update-Methode spendiere, in der er alle seine Werte updatet.

Nix mit Interface oder Basisklasse oder Delegaten - einfach einfacher Code:wobei die DriveSpace- und die TimeStamp- Properties auch noch sinnlos sind, weil von einem DriveInfo kann man jederzeit den AvailableSpace abfragen (dito mitte Uhrzeit).

Aber vlt. kommen ja noch zig weitere zu ermittelnde Werte hinzu

Ja, ist auch ne schöne Lösung, aber diese Klasse wird einfach nur eklig unübersichtlich, wenn noch weitere Komponenten hinzukommen. Schön alleine deswegen sollte man die einzelnen Komponenten in eigene Klassen aufteilen. Meine Meinung. Schon alleine der Konstruktor wird einfach nur übel, wenn noch Performance-Counter hinzukommen....

Imo sollte man da nix aufteilen, solange das Ermitteln eines Wertes mit ein oder 2 Zeilen getan ist.
Unter der Klassenbezeichnung "HardwareProperties" ist das eine Einheit, die man zunächstmal nicht auseinanderpflücken sollte.
Ich finde Klassen bis 200 Zeilen Code absolut gut lesbar - besser, als wenn man da zw. mehreren Dateien rumswitchen muß, um ein Gesamtbild zu erhalten.

Wohingegen ich mit meinem Datensatz-Ansatz noch VerkleinerungsPotential im Form-Code habe, wennich Databinding implementiere

Grade das mit den vielen EventHandlern bläst den Form-Codebehind enorm auf.
Grade Form-Codebehind wird ja bei anspruchsvollen Oberflächen sehr schnell unübersichtlich, und geht oft weit über 200 Zeilen hinaus.
Nicht nur unübersichtlich wegen der vielen Zeilen, sondern v.a. auch wegen der verschiedenen "Themen", die da beackert werden - da laufen ja Laden und Speichern, Optionen, TextChanges, alle möglichen Button-Clicks und alles zusammen, was inhaltlich eiglich nix mitnander zu tun hat.

im Anhang beide Lsg im Vergleich

Ja, geb ich Dir auch recht. Mit der Zeit entwickelt eben jeder seinen eigenen Programmierstil. Es geht auch nicht darum, dem TE seinen Stil aufzuzwingen. Mir gings halt damals so, als ich so etwas entwickeln wollte, waren Interfaces ein Fremdwort. Als ich mich damit befasste, hab ich viel dazu gelernt. Diesen "Sprung" wollte ich dem TE aufzeigen. Welches Beispiel er für sich als gut erachtet ist seine Sache. Immer führen viele Wege nach Rom und es ist gut, dass er unterschiedliche Herangehensweisen zu sehen bekommt.

Du hast bestimmt viel mehr Erfahrung wie ich und weisst auch mehr und vielleicht seh ich den Zusammenhang jetzt auch nicht. Darum ist ein Forum da. Das jeder seine Sicht kundtut und der TE sich dann seine Lösung für sich selbst erarbeitet.