Overriding .Enabled

[Phill. W]

Here's a knotty little problem.

I have some nasty little controls that needs to behave in a non-
windows-Standard way - don't ask why; it's a large application being
converted from some [much] older code and my users are adamant
that this behaviour mustn't change.

Specifically, I want to be able to set

myControl.Enabl ed = False

and, instead of the controls /actually/ being disabled, I want them to
/recolour/ themselves so that they /look/ disabled, but still respond to
Mouse events, can be copied from, and such like. (I realise the
ReadOnly property is going to be involved, here, but I don't think it
will do the whole job).

Adding to the complication; I thought I'd derive all of these controls
from a single ancestor UserControl and have that ancestor implement
an Interface containing the Enabled property (among other things), as in

Public Interface ITypeable
. . .
Property Enabled() as Boolean
. . .

Public Class Wrapper
Inherits UserControl
Implements ITypeable
. . .
Public Property Enabled() as Boolean _
Implements ITypeable.Enabl ed

And herein lies my problem.

The Enabled property already exists in UserControl, so when I try to
implement the Interface property, VB (2003) gets quite upset that the
specifiers or signatures on the Interface and Property don't match.
I've tried overloading, overriding, shadowing, and just about every
other modifier I can find on the Property and even overriding the
OnEnabledChange d routine, but I seem to be on a losing streak here.

Any Suggestions?

TIA,
Phill W.

I have a control that I don't want disabled when I set .Enabled = False,
when my code says
..Enabled = False
I have an application that uses UserConrols to

[yEaH rIgHt]

Public Interface ITypeable
Property Enabled() As Boolean
End Interface

Public Class Wrapper
Inherits Windows.Forms.U serControl
Implements ITypeable

Public Shadows Property Enabled() As Boolean Implements
ITypeable.Enabl ed
Get

End Get
Set(ByVal Value As Boolean)

End Set
End Property

End Class


"Phill. W" <P.A.Ward@o-p-e-n-.-a-c-.-u-k> wrote in message
news:c9******** **@yarrow.open. ac.uk...

Here's a knotty little problem.

I have some nasty little controls that needs to behave in a non-
windows-Standard way - don't ask why; it's a large application being
converted from some [much] older code and my users are adamant
that this behaviour mustn't change.

Specifically, I want to be able to set

myControl.Enabl ed = False

and, instead of the controls /actually/ being disabled, I want them to
/recolour/ themselves so that they /look/ disabled, but still respond to
Mouse events, can be copied from, and such like. (I realise the
ReadOnly property is going to be involved, here, but I don't think it
will do the whole job).

Adding to the complication; I thought I'd derive all of these controls
from a single ancestor UserControl and have that ancestor implement
an Interface containing the Enabled property (among other things), as in

Public Interface ITypeable
. . .
Property Enabled() as Boolean
. . .

Public Class Wrapper
Inherits UserControl
Implements ITypeable
. . .
Public Property Enabled() as Boolean _
Implements ITypeable.Enabl ed

And herein lies my problem.

The Enabled property already exists in UserControl, so when I try to
implement the Interface property, VB (2003) gets quite upset that the
specifiers or signatures on the Interface and Property don't match.
I've tried overloading, overriding, shadowing, and just about every
other modifier I can find on the Property and even overriding the
OnEnabledChange d routine, but I seem to be on a losing streak here.

Any Suggestions?

TIA,
Phill W.

I have a control that I don't want disabled when I set .Enabled = False,
when my code says
.Enabled = False
I have an application that uses UserConrols to

[Jay B. Harlow [MVP - Outlook]]

Phill,
Do you need to use Enabled specifically to implement the ITypeable.Enabl ed
property?

Have you consider naming Enabled, something other then Enabled?

Are you attempting to replace how UserControl.Ena bled itself operates? Or
should UserControl.Ena bled do what it normally does, while Wrapper.Enabled
does what you want?
The easiest route may be to use a different name for your Enabled property,
and ensure that UserControl.Ena bled is "not touched", except possible in the

Specifically, I want to be able to set
myControl.MyEna bled = False

Otherwise I suspect you will need some clever (fragile?) overloading,
shadowing, overriding, of the property & OnEnabledChange d method (you
probably need to use a combination of things that it sounds like you tried
individually).

Hope this helps
Jay

"Phill. W" <P.A.Ward@o-p-e-n-.-a-c-.-u-k> wrote in message
news:c9******** **@yarrow.open. ac.uk... Here's a knotty little problem.

I have some nasty little controls that needs to behave in a non-
windows-Standard way - don't ask why; it's a large application being
converted from some [much] older code and my users are adamant
that this behaviour mustn't change.

Specifically, I want to be able to set

myControl.Enabl ed = False

and, instead of the controls /actually/ being disabled, I want them to
/recolour/ themselves so that they /look/ disabled, but still respond to
Mouse events, can be copied from, and such like. (I realise the
ReadOnly property is going to be involved, here, but I don't think it
will do the whole job).

Adding to the complication; I thought I'd derive all of these controls
from a single ancestor UserControl and have that ancestor implement
an Interface containing the Enabled property (among other things), as in

Public Interface ITypeable
. . .
Property Enabled() as Boolean
. . .

Public Class Wrapper
Inherits UserControl
Implements ITypeable
. . .
Public Property Enabled() as Boolean _
Implements ITypeable.Enabl ed

And herein lies my problem.

The Enabled property already exists in UserControl, so when I try to
implement the Interface property, VB (2003) gets quite upset that the
specifiers or signatures on the Interface and Property don't match.
I've tried overloading, overriding, shadowing, and just about every
other modifier I can find on the Property and even overriding the
OnEnabledChange d routine, but I seem to be on a losing streak here.

Any Suggestions?

TIA,
Phill W.

I have a control that I don't want disabled when I set .Enabled = False,
when my code says
.Enabled = False
I have an application that uses UserConrols to

[Phill. W]

"Jay B. Harlow [MVP - Outlook]" <Ja************ @msn.com> wrote in message
news:%2******** *******@TK2MSFT NGP12.phx.gbl.. .

Do you need to use Enabled specifically to implement the
ITypeable.Enabl ed property?
Ideally, yes.
Have you consider naming Enabled, something other then Enabled?
Yes - regretably this control will be used by other Developers who
may not appreciate the difference and will cause the eventual Users
considerable confusion :-(
Are you attempting to replace how UserControl.Ena bled itself
operates? Or should UserControl.Ena bled do what it normally
does, while Wrapper.Enabled does what you want?

Using Wrapper.Enabled is ideally what I'm after, but I need to have
similar behaviours in a number of controls - some are UserControls,
some direct derivatives of, for example, Button. The only way I
know of doing that is with an Interface, but you have to define the
property in order to Implement it, and that's where Studio gets upset.

I think the confusion is that my Wrapper class has both an Enabled
property of its own and my Shadow Enabled property, taken from
my Interface so, if I say

Me.Enabled = whatever

will VB assume I want the inherent property rather than my Shadow?

Regards,
Phill W.

[Jay B. Harlow [MVP - Outlook]]

Phill,

I think the confusion is that my Wrapper class has both an Enabled
property of its own and my Shadow Enabled property, taken from
my Interface so, if I say
There's the rub, and the reason (the two distinct Enabled properties) I am
suggesting you avoid this. ;-)
Me.Enabled = whatever
Read very carefully what Shadows does for you. As Shadows is partially how
you will need to get this to work!

http://msdn.microsoft.com/library/de...keyShadows.asp

http://msdn.microsoft.com/library/de...et12252001.asp

http://msdn.microsoft.com/library/de...bspec4_2_3.asp

http://msdn.microsoft.com/library/de...nshadowing.asp

Shadows BREAKS polymorphism, most of the time you want polymorphism, I
normally only use Shadows to "protected the definition of my class members"
as the first link states. It is unlikely that I would start a new design,
such as this one, that relied on Shadowing! In other words Enabled means
Enabled, in both the derived classes & base class. It does not/should not
mean Enabled in the Control and readonly/something else hybrid in the
derived classes. It can however mean Enabled in the Control, while meaning
Enabled+ in the derived class. Normally the designers of the base class mark
the member (property) as Overridable in the base class to allow you to
define Enabled+ in the derived classes...
When you Shadow the Enabled property, if you refer to Enabled via a base
class you will get the base class's Enabled, if you refer to Enabled via the
derived class you will get the derived class's Enabled.

Public Class Wrapper
Inherits Control ' any control: Button, UserControl, etc...
Public Shadows Property Enabled As Boolean
...

Public
End Class

Dim wrapper As New Wrapper

wrapper.Enabled = True ' will change Wrapper.Enabled

Dim base As Control = wrapper
base.Enabled = True ' will change Control.Enabled , not Wrapper.Enabled
which is probably desired.

' within Wrapper
Me.Enabled = True ' will change Wrapper.Enabled

MyBase.Enabled = True ' will change Control.Enabled

Are you attempting to replace how UserControl.Ena bled itself
operates? Or should UserControl.Ena bled do what it normally
does, while Wrapper.Enabled does what you want?

Using Wrapper.Enabled is ideally what I'm after, but I need to have
similar behaviours in a number of controls - some are UserControls,

You did not really answer this question. Should Control.Enabled only do what
Control.Enabled currently does, or should it behave as your new
Wrapper.Enabled property?

Are you using the Interface polymorphically ? (do you use the interface as a
parameter to other methods?) If you aren't using the interface
polymorphically I don't know if I would keep it, of course if you want to
have the set of methods in all your classes its handy to keep, I would need
to have a better idea of what is really in the interface to decide. Part of
the point here is that Control already has Enabled, do you really need
Enabled in the Interface...

Anyway I would approach the solution something like:

Public Interface ITypeable

Property Enabled() As Boolean

End Interface

Public Class Wrapper
Inherits UserControl
Implements ITypeable

Private Property ITypeable_Enabl ed() As Boolean Implements
ITypeable.Enabl ed
Get
Return Enabled
End Get
Set(ByVal value As Boolean)
Enabled = value
End Set
End Property

Protected Overrides Sub OnEnabledChange d(ByVal e As
System.EventArg s)
MyBase.OnEnable dChanged(e)
' do the logic for Enabled changing
End Sub

End Class

This gives you Enabled in the Interface, it gives Wrapper Enabled+, it
allows Enabled to continue to be Enabled.

If you don't want Enabled+ (IMHO bad idea) you can try something like:

Public Class Wrapper
Inherits UserControl
Implements ITypeable

Public Shadows Property Enabled() As Boolean Implements
ITypeable.Enabl ed
Get

End Get
Set(ByVal value As Boolean)

End Set
End Property
Protected Overrides Sub OnEnabledChange d(ByVal e As
System.EventArg s)
MyBase.OnEnable dChanged(e)
If MyBase.Enabled Then
' do something based on Control.Enabled
ElseIf Me.Enabled Then
' do something based on Wrapper.Enabled
End If
End Sub

End Class

Hope this helps
Jay

"Phill. W" <P.A.Ward@o-p-e-n-.-a-c-.-u-k> wrote in message
news:c9******** **@yarrow.open. ac.uk... "Jay B. Harlow [MVP - Outlook]" <Ja************ @msn.com> wrote in message
news:%2******** *******@TK2MSFT NGP12.phx.gbl.. .

Do you need to use Enabled specifically to implement the
ITypeable.Enabl ed property?

Ideally, yes.

Have you consider naming Enabled, something other then Enabled?

Yes - regretably this control will be used by other Developers who
may not appreciate the difference and will cause the eventual Users
considerable confusion :-(

Are you attempting to replace how UserControl.Ena bled itself
operates? Or should UserControl.Ena bled do what it normally
does, while Wrapper.Enabled does what you want?

Using Wrapper.Enabled is ideally what I'm after, but I need to have
similar behaviours in a number of controls - some are UserControls,
some direct derivatives of, for example, Button. The only way I
know of doing that is with an Interface, but you have to define the
property in order to Implement it, and that's where Studio gets upset.

I think the confusion is that my Wrapper class has both an Enabled
property of its own and my Shadow Enabled property, taken from
my Interface so, if I say

Me.Enabled = whatever

will VB assume I want the inherent property rather than my Shadow?

Regards,
Phill W.