Die Frage ist so wenig sinnvoll. Von was für einem Timer reden wir und wie wird er eingesetzt?

Grüße

Kommt auf den Anwendungsfall an.

Jou.
@Facebamm Wofür brauchst Du (k)einen Timer?

Also wirds du um einen Timer nicht drum herum kommen?

Kommt immer drauf an für was du den Timer brauchst...

Alles was per Event zu erledigen ist, würde darüber abbilden. Was periodisch ist, kann man durchaus mit einem Timer lösen.

@Facebamm interessant, das schau ich mir mal an.

Unter WPF kannst du auch einen DispatchetTimer verwenden.

Facebamm schrieb:

WinForm-Timer

Wenn Du den Code in einen Thread auslagerst, nimm einen Threading.Timer, da wird die GUI nicht bei ausgebremst.

Hi
ich würde das definitiv in einen eigenen Thread auslagern und dort den Ablauf sinnvoll regeln. Und ich würde auch darauf achten, dass die GUI-Invokes, usw. asynchron ablaufen, damit der TCP-Handler nicht ausgebremst wird (System.Threading.ThreadPool.QueueUserWorkItem ist dein Freund).
Um es genauer zu beschreiben: In meinem Konstrukt gäbe es clientseitig einen Thread, der Read und Write für die Daten, die über den Tcp-Client geschickt werden sollen. Sobald auf eine empfangene Nachricht reagiert wird, erzeugt er z.B. einen Delegaten oder eine Klasse, die das auszuführende Ereignis beschreibt. Dieses Ereignis wird dann erneut asynchron behandelt, d.h. eben über QueueUserWorkItem oder einen separaten Thread, der ebenfalls von dir erzeugt wird (dazu hättest du eine Queue, die alle Nachrichten enthält, die es noch zu verarbeiten gilt). Beachte, dass du in diesem Modell auf jeden Fall Synchronisierungsmaßnahmen hast.

Viele Grüße
~blaze~

mrMo schrieb:

Kommt auf den Anwendungsfall an.

@Facebamm Der WinForms-Timer läuft im GUI-Thread, da kannst Du also voll auf GUI-Elemente zugreifen.
Andere Timer arbeiten in einem separaten Thread, da kannste nich auf GUI-Elemente zugreifen.
Also: Je nach Deiner Situation.