[C#] Timer in GUI of aparte classe

[4of9]

Hallo,

Ik zal mijn titel even verduidelijken.

Ik heb een winforms applicatie. Een soort van Countdown clock.

Ik heb een classe timehandler. Deze berekend hoeveel tijd er nog over is. Op mijn Form heb ik een timer die om de 100 ms afgaat.

Deze invoked dan een delegate die wijst naar mijn TimeHandler.CalculateTime()

Doe ik dit goed of moet ik het net andersom doen? Dus een timerstarten in de TimeHandler en dan een method op de GUI invoken?

Wat zijn de best practices hier? En moet ik mijn timer ook in een aparte thread stoppen?

alvast bedankt!

[whoami]

Waarom zou je die timer in een aparte thread stoppen ?

Wat je zou kunnen doen, om het geheel wat te abstraheren, is een class maken 'Countdown', die een Timer bevat, en een public event 'CountDownChanged'. Je timer wordt dan afgevuurd op een bepaald ogenblik, en in je class bereken je de tijd.
Een windows form kan zich abboneren op je CountDownChanged event, en op die manier tonen hoeveel tijd er nog resteert. (Je kan de resterende tijd meegeven als parameter van de event-handler voor die CountDownChanged event)

[4of9]

Dus het is beter om de GUI zich te laten abboneren op een event in een classe dan dat een classe zich abboneert op een GUI event?

Ik dacht btw aan threading voor responsiveness van de gui maar het gaat in principe gewoon goed dus dat is niet meer nodig.

[Orphix]

Het gaat niet zozeer om de manier van koppelen (GUI->class of andersom), maar om de abstractie. Als je als 'gebruiker' (ook wel client-programmer) naar jouw 'TimeHandler' component kijkt, dan is het vreemd dat je naast je TimeHandler object, daarnaast ook nog een timer object moet aanmaken, en die moet koppelen.
Het aftellen en het bijhouden van de resterende tijd is de taak van een en dezelfde class. Dat is wat Whoami duidelijk maakt. En in het geval van een component die zowel aftelt als de resterende tijd bijhoudt, is de class naam 'Countdown' een betere (meer beschrijvend) dan 'TimeHandler'.

[Depress]

4of9 schreef op vrijdag 02 februari 2007 @ 14:15:
Dus het is beter om de GUI zich te laten abboneren op een event in een classe dan dat een classe zich abboneert op een GUI event?

Ik dacht btw aan threading voor responsiveness van de gui maar het gaat in principe gewoon goed dus dat is niet meer nodig.

Het voordeel van een een klasse is de modulariteit, het is dus dan ook vanzelfsprekend dat je je klasse niet afhankelijk maakt van je GUI. Dus de GUI op een event van de klasse laten abboneren is dan de correcte oplossing. Maar dit is geheel je eigen beslissing... De herbruikbaarheid van je klasse neemt wel een stuk af...