>Oh, bother. I can see another flaming thread forming here...

Pertti,

I'm not gonna get into a flame war with you, so I won't even address your comments.

But I *will* say that I'm an idiot, because it isn't necessary to create a new property to take care of this. My bad!!!! <g> I just spit out a quick post last night without thinking too much about it. I should have known better.

Even though the ReadOnly property isn't overridable, you can still have your own ReadOnly property by specifying "new" when you create it. Actually, you don't even have to specify the "new", but you get a compiler warning if you don't ... no big deal:

public class MyTextBox : System.Windows.Forms.TextBox
{
	public MyTextBox
	{
		this.ReadOnly = true;
	}

	[DefaultValue(true)]
	public new bool ReadOnly
	{
		get {return base.ReadOnly;}
		set {base.ReadOnly = value;}
	}
}

Sorry for the erroneous code earlier. =0(

~~Bonnie



>
>Bonnie, does this kind of inheritance model (exception) make sense to you? And if it does, why? I don't personally see what the reason might possibly be, but then again, what do I know.
>
>Maybe I'm missing something (big) here, but I can't see why the HECK I can't simply and codelessly overwrite parent class' properties like ReadOnly and Enabled and Font in a child class. It is sooooo counterintuitive and annoying to me to have to keep these kinds of exceptions in my already overloaded memory banks. Wasted storage, as far as I'm concerned. Isn't this one of the cornerstones of OOP inheritance: If a PEM is visible and accessible in the parent, it should be always and freely overrideable in the child. Period.
>
>I am now tempted to say something about VFP's consistent OOP implementation, but I think I better not, because it could so easily sidetrack any possible follow-up discussion here. So, I'm hereby not saying anything about VFP's consistent OOP implementation.
>
>Thanks.
>
>
>Pertti
>
>
>>I was going to suggest overriding the ReadOnly property, as some examples floating around here lately were showing with overriding the Font or BackColor properties. Unfortunately though, the ReadOnly property is not overridable. So, instead, create your own property and call it SetReadOnly, or something similar. We do that with our controls for the Enabled property, since it's not overridable either. Sorry for the C# code:
>>
>>

>>public class MyTextBox : System.Windows.Forms.TextBox
>>{
>>	private bool m_SetReadOnly;
>>
>>	public MyTextBox
>>	{
>>		this.m_SetReadOnly = true;
>>	}
>>
>>	[DefaultValue(true)]
>>	public bool SetReadOnly
>>	{
>>		get {return this.m_SetReadOnly;}
>>		set
>>		{
>>			this.m_SetReadOnly = value;
>>			this.ReadOnly = value;
>>		}
>>	}
>>}
>>

>>
>>
>>~~Bonnie
>>
>>
>>
>>>OK, now it is my turn to ask a question about custom controls... *ducks*
>>>
>>>Hopefully this is an easy one, as I think I am just misunderstanding what I am supposed to do. I created a class called MyTextBox, and inherited from System.Windows.Forms.TextBox, and I could place my custom control on the form. Now, to play around with it I tried to set some defaults, specifically setting ReadOnly = True. It didn't seem to carry forward into the control I dropped.
>>>
>>>Here is my code:
>>>

>>>Public Class MyTextBox
>>>    Inherits System.Windows.Forms.TextBox
>>>
>>>    Public Sub New()
>>>
>>>        MyBase.New()
>>>
>>>        Me.ReadOnly = True
>>>
>>>    End Sub
>>>
>>>End Class
>>>

>>>
>>>Any guidance? Thanks!