When to add a component versus a class

[John Granade]

I'm sure this has been asked but after searching the Internet, I just can
find a clear answer. When should you add a component versus a class to you
Windows Forms application?

The timer is a good example. I'm planning to add a customer system.timer to
run that should be accessible from several forms so I don't want to use the
forms timer. Should I add this to a new class or new component?

Thanks,

John

[Herfried K. Wagner [MVP]]

* "John Granade" <jo**@granade.net> scripsit:

I'm sure this has been asked but after searching the Internet, I just can
find a clear answer. When should you add a component versus a class to you
Windows Forms application?

The timer is a good example. I'm planning to add a customer system.timer to
run that should be accessible from several forms so I don't want to use the
forms timer. Should I add this to a new class or new component?

Class.

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

[Cor]

Hi John,

I would not write a timer in a seperate class.

It is totaly complete, there is nothing reusable by setting it in a seperate
class, why would you seperate it. (There are people who transporting there
car with a truck but most don't)

But would you make your own clock and you want to put that on more pages,
than that clock would hold a timer itself of course to let the indicator go
smooth and not eat up completly your system.

Just my 2 eurocents.

Cor

I'm sure this has been asked but after searching the Internet, I just can
find a clear answer. When should you add a component versus a class to you Windows Forms application?

The timer is a good example. I'm planning to add a customer system.timer to run that should be accessible from several forms so I don't want to use the forms timer. Should I add this to a new class or new component?

[Tom Leylan]

"Cor" <no*@non.com> wrote...

I would not write a timer in a seperate class.

It is totaly complete, there is nothing reusable by setting it in a seperate class, why would you seperate it. (There are people who transporting there
car with a truck but most don't)

Oops... keep in mind that reusability isn't the only goal. People transport
their car by "ship" all the time by the way, it's hard to drive a car made
in the UK, Germany or Italy to the US.

By encapsulating a generic timer within a specific timer class the behaviors
are guaranteed to be consistent across the application. ATimer.Reset()
would (regardless of who called it (or from where)) always reset ATimer to
the proper setting. If every routine can reset it a common timer to any
value it wants one of them will surely get it wrong.

Tom

[Cor]

Hi Tom,

I have thought about such a thing, but doing that I thought also if it is in
a project good if from everywhere a timer can be reseted.

But maybe there are circumstances and than I agree.

But I was knowing while writing this I was on slippery ground.

:-))

Cor

By encapsulating a generic timer within a specific timer class the behaviors are guaranteed to be consistent across the application. ATimer.Reset()
would (regardless of who called it (or from where)) always reset ATimer to
the proper setting. If every routine can reset it a common timer to any
value it wants one of them will surely get it wrong.

[Cor]

Hi Tom,

Maybe it is in the USA more normal, but I once was on a camping place in
Spain, and there was someone who had a campingcar in which he was
tranporting his car.

You know the distances in Europe, I found it funny to see.

Cor

[Herfried K. Wagner [MVP]]

Cor,

* "Cor" <no*@non.com> scripsit:

I would not write a timer in a seperate class.

It is totaly complete, there is nothing reusable by setting it in a seperate
class, why would you seperate it. (There are people who transporting there
car with a truck but most don't)

I am still not sure if the OP wants to /write/ a timer or if he wants to
/use/ an existing timer class.

Just my 2 Euro cents...

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

[Tom Leylan]

Hi Cor:

I'm not into "good or bad" :-) I think the guy said he needed it to be
accessible from many places. Despite that however it can be useful to
customize a timer class rather than remember to set a lot of common settings
every time you want one to be configured a particular way.

It's not entirely unlike a method that returns a connection string for
ADO.Net. One can always hardcode the string at the place it is used but
there is no advantage to doing that right? It makes it hard to change and
one of them will get messed up.

So if he needs a timer configured a standard way (even if it isn't accessed
globally) why not just ask for one preconfigured?

Tom
"Cor" <no*@non.com> wrote in message
news:eK**************@tk2msftngp13.phx.gbl...

Hi Tom,

I have thought about such a thing, but doing that I thought also if it is in a project good if from everywhere a timer can be reseted.

But maybe there are circumstances and than I agree.

But I was knowing while writing this I was on slippery ground.

:-))

Cor

By encapsulating a generic timer within a specific timer class the

behaviors

are guaranteed to be consistent across the application. ATimer.Reset()
would (regardless of who called it (or from where)) always reset ATimer to the proper setting. If every routine can reset it a common timer to any
value it wants one of them will surely get it wrong.

[Jay B. Harlow [MVP - Outlook]]

John,
The timer example aside.
I create a new Component when I want either a Visual Designer to help build
the class (by dragging & dropping other components onto it) or I want to
drag & drop this new Component onto another Visual Designer (such as another
Component or Form). Otherwise I create a Class.

I don't think I would create a new Component, just to drag a single
Component (System.Timer) onto it, unless that Component was easier to
configure from a Visual Designer then straight code.

Remember that Component is a Class that inherits from
System.ComponentModel.Component (more importantly they implement the
IComponent interface). The biggest benefit I see with Components is the
visual designer support in VS.NET.

Hope this helps
Jay

"John Granade" <jo**@granade.net> wrote in message
news:O8**************@TK2MSFTNGP10.phx.gbl...

I'm sure this has been asked but after searching the Internet, I just can
find a clear answer. When should you add a component versus a class to you Windows Forms application?

The timer is a good example. I'm planning to add a customer system.timer to run that should be accessible from several forms so I don't want to use the forms timer. Should I add this to a new class or new component?

Thanks,

John