tags:

views:

301

answers:

3

I have read over this which sort of gives an explanation of when you'd choose Web Control vs. Control when creating custom controls but it's not quite enough. I've seen custom controls inherit from either when they're both rending out stuff to the UI.

http://msdn.microsoft.com/en-us/library/yhzc935f.aspx

"If your control renders a user interface (UI) element or any other visible element on the client, you should derive your control from System.Web.UI.WebControls..::.WebControl (or a derived class). If your control renders an element that is not visible in the browser, such as a hidden element or a meta element, derive your control from System.Web.UI..::.Control. The WebControl class derives from Control and adds style-related properties such as Font, ForeColor, and BackColor. In addition, a control that derives from WebControl participates in the themes features of ASP.NET without any extra work on your part. "

so the only reason to use WebControl is if you want to use their styling features? I'm just going to output strings with a stringbuilder utlimately so I don't care about that stuff. I'd prefer to use straight up tableless design and strings to form my HTML that my control renders anyway.

+1  A: 

WebControl doesn't render tables or anything like that unless you tell it to. What it does have is the styling features that most users will expect from a control that renders with a UI.

It doesn't cost you much to use it. Give it a try and see if it causes you any problems.

John Saunders
are you talking about it provides properties such as cssClass, etc.?
CoffeeAddict
My control is spitting out HTML specified from our DB table from our CMS system that a user has inputted through our CMS Admin system. Any styling will either be in that HTML already or in any elements such as divs that I wrap this content in the logic behind the scenes with my custom control. So I don't foresee a need for cssClass, etc. as my control will handle that. So if I inherit from Control it's still going to output some major UI components but there is no need to be styling this during runtime.
CoffeeAddict
Ok, that makes sense, and yes, I was talking about CssClass, BackColor, BorderColor, etc.
John Saunders
+3  A: 

Control

Deriving from the Control class allows our control to take advantage of the rendering methods provided by the Control class, as well as the use of ViewState.

WebControl

The WebControl class derives from the Control class. However, if we derive our custom control from WebControl, we get free support for many visual aspects of our control, like font size, CSS classes, background colour and so on.

Which class should I derive from?

When you are creating a custom control that requires little or no UI, then you should derive from the Control class. If your control does require the need for extensive UI support, then you should derive from WebControl.

From: http://dotnetslackers.com/articles/aspnet/ASPNETCustomControlsPart1.aspx

SolutionYogi
OK so the only REAL tangeable benefit from a "good standards" point of view is that if you're going to use WebControl, then whoever implements your control can use CssClass on that control. All theothers like font-size, background-color is trash, as you should always use a .css with styles and IDs in your code.
CoffeeAddict
When you are creating a custom control that requires little or no UI, then you should derive from the Control class. If your control does require the need for extensive UI support, then you should derive from WebControl. Ok but I can see with my point of view, that the only reason I'd want WebControl is to provide the cssClass attribute. So if your control is spitting out lets say some UI content based on a CMS system and you have no need to specify a cssClass (because you're doing that through your logic in your custom server control behind the scenes) then don't use WebControl
CoffeeAddict
A: 

So, do you have a question to ask? I think the differences between the two were well addressed in the MSDN article.

Janie
Just trying to verify if there's really any other benefit to using WebControl other than getting a cssClass attribute. And that inheriting from Control doesn't mean you're not going to be styling it, that you can always use plain styles in your custom control methods. Really I just don't see a benefit to using WebControl unless you ultimately need cssClass attribute available is what I am concluding personally.
CoffeeAddict
Here's the problem, all that was spit back was that MSDN article that I just read. I understand that but this statement here: "When you are creating a custom control that requires little or no UI, then you should derive from the Control class". What the heck does that mean, that you're not goign to render HTML (UI) or do they mean if you don't need STYLES. it's a poor choice of words on that page. That sentence makes it say as though you're not rendering any UI at all. They mean styling.
CoffeeAddict
It goes on to say "If your control renders a user interface (UI) element or any other visible element on the client, you should derive your control from System.Web.UI.WebControls..::.WebControl". Not true. IN my case it's gonna spit out a lot of UI...but users should not be adding any css class to it.
CoffeeAddict
so that's the problem I have with their context of WHY to use either or. You can still be spitting out a crapload of HTML form your control but really if you don't want anyone adding a cssClass or other attributes, you still use Control to render your crapload of HTML. I don't like how they define the reason to use one vs. the other and choice of words basically.
CoffeeAddict
You could have something dervied from Control that emits a bunch of javascript for instance (this obviously being non-visual)
Janie
yep, and I've done that before.
CoffeeAddict