Do you really avoid these problems by using a composite control in a
single project with your executable? If so, and your ap is actually small
enough you have no need for separately compiled modules, that would be the
way to go. Keep things as simple as possible. (Can you just expose the
whole TextBox as a public property? When we use composite controls, we
expose only the properties we actually use, one at a time, which is a good
bit of work up front but we think worth it.)
My own experience is that we do have a need to put things in modules to
make patch sizes reasonable. And we are using enough different custom
controls that it is worth having them in a library. In fact, we keep them
in a separate solution. This reminds us to completely close main project
before working on controls, and completely close controls project after
making changes & doing basic sanity testing on them (there is a small test
project in the controls library solution that doesn't compile on a release
build.) You avoid caching issues by completely closing, reopening after
making changes to controls. In a product of large scope, you won't be
making a lot of changes to the library by the time you get very far into
the main project.
-Rachel
Stoitcho Goutsev (100) said:
Rachel,
Yes, you are right. The only downsite is that there is a need of separate
project for that controls (separate assembly) and the other problem is
that the toolbox caches the controls and it could be bad experience when
change the source of the control.
But, yes it can be done this way.
--
Stoitcho Goutsev (100) [C# MVP]
Rachel Suddeth said:
Sure you can. I've done it. You start by creating a class library for
the new control. Any kind of project that will compile to a DLL will do.
Then you write your control class, eg:
-----
using System;
using System.Data;
using System.Collections;
using System.ComponentModel;
using System.Drawing;
using System.Windows.Forms;
namespace TextBoxTest
{
public class MyTextBox : System.Windows.Forms.TextBox
{
public string tp = "";
public MyTextBox(){}
public string TestProperty{ get{return tp;} set{tp = value;} }
}
}
------
(I probably don't need all those "usings", but...)
Now compile that. Create an executable project with a form. Add a
reference to the library you just created. Go to tool box,
right-click/Add Items/Browse, find the DLL for your library project. The
new control will appear in the tool box and you can put it on your form.
You can set the TestProperty or any other TextBox properties in the
designer. You can mess with them in code. It all works.
-Rachel
Hi Rachel,
If you inherit from the TextBox control, then whenever you place
the derived control on a form
There is the catch. You can not place it in the form. You can only
create it dynamically, which means it won't appear at design time.
Unless. as I said, you don't do your own designer.
Furthermore, it you add a special property (maybe something
FormatString), and it is something basic like a string, you will be
able to edit that property from the visual designer when using the
control, without having to add any designer code.
Completely correct if you could (but you can't) put it on the form.
