I'm sorry to be so persisent about this, but I want to tell you that I made the class without the Get, Set and DefaultValue stuff, and it works just fine... When I change the font color or size in the class, and then re-build project and run the form, it comes out just like the class changes. No Get. No Set. No DefaultValue. It just works.

Now, to see the changes in the form while in the IDE, you will have to close and re-open the form. But at any time, if I change the font in the class, the textbox on the form automatically updated to match the form, when you run it, or re-open it. Again, No Get. No Set. No DefaultValue.




>>In a previous post, *YOU* said putting all this in the constructor was a no-no (or at least it would have un-desired side-effects):
>
>Either I didn't state it clearly or you misunderstood. Sorry Matt. =0(
>
>If you set visual properties in your constructor, then you *have to* override those same properties (color, font, etc.) and give them [DefaultValue] attributes ... what is a no-no is doing one without the other.
>
>>Now, I definately do NOT want to have to "revisit every single form...", but maybe that just applies to dealing with the the Default Value re-setting of the property in the IDE. I do not so much care about the "default value" in the IDE part, but I do want to control visual things like color, font, size, from a central class so that they will automatically re-propogate to all forms when I change the base class.
>
>And consequently you'll need both code in the constructor *AND* properties (get/set) defined with the DefaultValue attribute. Sorry, that's just the way it has to be.
>
>I should have looked a little more carefully at your TextBox (I didn't notice the color and font and stuff), so my simplified version wasn't quite that simplified was it? <g> Sorry, that was my fault. =0(
>
>~~Bonnie
>
>
>
>
>
>>Wait a minute!!! ( I'm saying that kindly...) There must be something I still do not understand...
>>
>>In a previous post, *YOU* said putting all this in the constructor was a no-no (or at least it would have un-desired side-effects):
>>
>>You said:
>>
>>That second point is pretty important. Let's use a TextBox as an example, along with it's BackColor property. Say that you've not used the [DefaultValue] attribute in your TextBox, and simply set the value of the BackColor in your TextBox's constructor so that it looks like this:
>>
>>
>>

>>public class MyTextBox : TextBox
>>{
>>	public MyTextBox()
>>	{
>>		this.BackColor = Color.DarkGreen;
>>	}
>>}
>>

>>
>>
>>When you drop this TextBox onto a Form, the BackColor will be explicitly set in code to Color.DarkGreen in the InitializeComponent() method of the Form. Consequently, if you later decide to change the color in your MyTextBox class, you have to revisit every single Form that you ever dropped that TextBox on to change it to the new default value. Not good!
>>
>>
>>Now, I definately do NOT want to have to "revisit every single form...", but maybe that just applies to dealing with the the Default Value re-setting of the property in the IDE. I do not so much care about the "default value" in the IDE part, but I do want to control visual things like color, font, size, from a central class so that they will automatically re-propogate to all forms when I change the base class.
>>
>>So, it is starting to seem like I CAN use the contstructor do achieve what I want, as long as I don't care about the IDE re-setting of the Default Value thing.
>>
>>Is that correct?
>>
>>Your expanded version required adding Get and Set methods and the whole really began to explode way beyond what I was expecting, but the Constructor-only way is much more (in fact exactly) what I was looking for.
>>
>>

>>
>>
>>public class MyTextBox : TextBox
>>{
>>	public MyTextBox()
>>	{
>>	}
>>	
>>	[DefaultValue(typeof(System.Drawing.Color), "DarkGreen")]
>>	public override System.Drawing.Color BackColor
>>	{
>>		get {return base.BackColor;}
>>		set {base.BackColor = value;}
>>	}
>>}
>>
>>

>>
>>
>>
>>
>>
>>>This doesn't work. Have you tried dragging that "Component TextBox" from the ToolBox onto a Form? Seems it disappears somewhere ... well, it's not visible anyway. Components are not meant to be used this way.
>>>
>>>The preferable way to do this is to create one file that holds most of these simple types of controls (TextBox, ComboBox, ListBox, ListView, CheckBox, etc.), as I have previously mentioned.
>>>
>>>As far as the purpose of a Component class, here's what the documentation says about it:
>>>
>>>Component is the base class for all components in the common language runtime that marshal by reference. Component is remotable and derives from the MarshalByRefObject class. Component provides an implementation of the IComponent interface. The MarshalByValueComponent provides an implementation of IComponent that marshals by value.
>>>
>>>You can host a Component in any object that implements the IContainer interface, and you can query and get services from its container. The container creates an ISite for each Component it contains. The container uses the site to manage the Component and is used by the Component to communicate with its container.
>>>
>>>That certainly doesn't sound like something I want to stick a TextBox on. <g>
>>>
>>>Your TextBox class would simply look something like this, which seems much simpler to me:
>>>
>>>

>>>    public class MattsTextBox : OakLeaf.MM.Main.Windows.Forms.mmTextBox
>>>    {
>>>        public MattsTextBox()
>>>        {
>>>            this.BindingSourceMember = null;
>>>            this.ControlID = new System.Guid("00000000-0000-0000-0000-000000000000");
>>>            this.Font = new System.Drawing.Font("Arial", 9.75F, System.Drawing.FontStyle.Bold, System.Drawing.GraphicsUnit.Point, ((byte)(0)));
>>>            this.ForeColor = System.Drawing.Color.Red;
>>>            this.Location = new System.Drawing.Point(0, 0);
>>>            this.Name = "mmTextBox1";
>>>            this.Size = new System.Drawing.Size(100, 22);
>>>            this.TabIndex = 0;
>>>        }
>>>    }
>>>}
>>>

>>>
>>>
>>>~~Bonnie