By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,337 Members | 2,234 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,337 IT Pros & Developers. It's quick & easy.

Derived Form Controls or Custom User Controls

P: n/a
Hey,

I'm trying to figure out what situations call for the use of a derived
form control such as:

public class myListBox : System.Windows.Forms.ListBox

and what situations call for the use of a Custom User Control, generated
by adding a new Custom User Control to a project with VS.NET.

Playing around so far, I found the idea of creating a Customer User
Control and adding a ListBox control to it, kind of ugly. But the
advantage being that I can set it's Custom Tool name and drag and drop
it on to a form with the designer like any of the other controls . The
problem here is that I have to edit the Customer User control to change
the properties of the listbox.

Is there a way to derive a new control from an existing one (as with the
System.Windows.Forms.Listbox example above) and have the drag and drop
functionality with the designer? Is the only way to add a derived
control to a form through the code? And if so, I can't have the code to
add the control inside the designer generated InitializeComponent
function, I have to add it somewhere else right?

I'd really appreciate if someone could help clear up some of my
confusion on this matter. Thanks.

-Paradox a.k.a. Aaron

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Nov 16 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
I searched around on the internet and found this article:

http://www.akadia.com/services/dotne..._controls.html

It answers some of my questions. However, is there no way to add an
inherited control to the toolbox without creating a seperate assembly?
The reason for adding to the toolbox is so I can use the designer to add
it to the form.

Maybe I should ask a different question. My goal is more about
encapsulation rather than creating a resuable user control or tool. I
can't see putting all the functions that deal with all the controls of a
form in the form class. For example, say I have a form with a listbox
that lists customer information from a database and a few buttons: 'Add
Customer', 'Delete Customer', and 'Cancel'.

I would like to have the listbox manage all of its own functions and the
form call those functions. For example, the listbox needs to connect to
the database and get the customers and then populate itself. If I
created an inherited control I could do this easy by adding a new
function called: GetCustomers(). Then the form just needs to call:
myListBox.GetCustomers(). And when a user selects a row of the listbox
and clicks the 'Delete Customer' button, it calls another function:
myListBox.DeleteSelected(). Doesn't this make sense?

Creating a user control and then adding a listbox control to it,
encapsulates the listbox itself; meaning adding the user control to the
form using the designer, and then viewing the properties shows the
available properties for a UserControl object, not a ListBox. This is an
undesired result.

I don't want to have to compile an inherited control as a seperate
assembly either. Again its not about creating a reusable control, its
about encapsulation. I especially don't want to give someone else the
ability to add this control to one of their forms.

Are they're any books out there that discuss how to maintain the OOP
pardigm when programming with windows forms and controls in C# and
VS.NET? Thank you.

-Paradox a.k.a. Aaron

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Nov 16 '05 #2

P: n/a
I haven't found an easy way to add an inherited control to the toolbox unless it
is in an assembly. If I don't want to do that, what I usually do is add a
regular ListBox (or whatever control I want to override) to the form so the
appropriate InitializeComponent code is created in the form. After you save the
form, go to the code and substitute your class for the generic ListBox class in
two places:

1) The control variable declaration
private System.Windows.Forms.ListBox listbox1;

to

private MyDerivedListBoxClass listbox1;

2) The place where the list box object is instantiated in InitializeComponent:
this.listbox1 = new System.Windows.Forms.ListBox();

to

this.listbox1 = new MyDerivedListBoxClass();

After you save and compile, the form will now use your derived ListBox class.
You can set properties/events and interact with the control in the designer just
as if you had added it from the Toolbox. You only need to do this once for that
particular form.

It's not as convenient as having your derived ListBox sitting in the Toolbox,
but if you don't have to do this very often it is an easy alternative.

Hope this helps.

--
Rodger Constandse

<http://www.SequenceDiagramEditor.com>
Sequence Diagram Editor - A quick and easy way to draw and edit sequence diagrams.

Paradox wrote:
I searched around on the internet and found this article:

http://www.akadia.com/services/dotne..._controls.html

It answers some of my questions. However, is there no way to add an
inherited control to the toolbox without creating a seperate assembly?
The reason for adding to the toolbox is so I can use the designer to add
it to the form.

Maybe I should ask a different question. My goal is more about
encapsulation rather than creating a resuable user control or tool. I
can't see putting all the functions that deal with all the controls of a
form in the form class. For example, say I have a form with a listbox
that lists customer information from a database and a few buttons: 'Add
Customer', 'Delete Customer', and 'Cancel'.

I would like to have the listbox manage all of its own functions and the
form call those functions. For example, the listbox needs to connect to
the database and get the customers and then populate itself. If I
created an inherited control I could do this easy by adding a new
function called: GetCustomers(). Then the form just needs to call:
myListBox.GetCustomers(). And when a user selects a row of the listbox
and clicks the 'Delete Customer' button, it calls another function:
myListBox.DeleteSelected(). Doesn't this make sense?

Creating a user control and then adding a listbox control to it,
encapsulates the listbox itself; meaning adding the user control to the
form using the designer, and then viewing the properties shows the
available properties for a UserControl object, not a ListBox. This is an
undesired result.

I don't want to have to compile an inherited control as a seperate
assembly either. Again its not about creating a reusable control, its
about encapsulation. I especially don't want to give someone else the
ability to add this control to one of their forms.

Are they're any books out there that discuss how to maintain the OOP
pardigm when programming with windows forms and controls in C# and
VS.NET? Thank you.

-Paradox a.k.a. Aaron

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

Nov 16 '05 #3

P: n/a
Well, one solution I figured... I added a standard datagrid to a form.
Created a class that inherits the datagrid and then went back into the
form's code and changed it to use the inherited class. I had thought
that if I did this, it would get overridden when I tried to modify the
properties of the datagrid or other form elements, however, it seems to
be working. Is this a good approach?

-Paradox a.k.a. Aaron

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Nov 16 '05 #4

P: n/a
LoL... Thanks! I had just figured that out and must of been typing that
last post when you were typing yours. Either way, I very much appreciate
the response.

-Paradox a.k.a. Aaron

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Nov 16 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.