The Enabled property is an odd beast. It's an extender property, but the Extender object doesn't provide it unless your control has an Enabled property of its own, with the correct procedure ID. If the extender's Enabled property isn't present, your control will not display the same enabled/disabled behavior as other controls.
Your property should delegate to the Enabled property of the UserControl object, as shown in the following code sample:
Public Property Get Enabled() As Boolean
Enabled = UserControl.Enabled
End Property
Public Property Let Enabled(ByVal NewValue As Boolean)
UserControl.Enabled = NewValue
PropertyChanged "Enabled"
End Property
Add this code to the code window of the UserControl your ActiveX control is based on, as discussed in "Adding Properties to Controls," later in this chapter.
Note You can easily add the Enabled property by using the ActiveX Control Interface Wizard to create the interface for your control. The wizard includes the Enabled property in its list of recommended properties.
Notice that the Enabled property of the UserControl object is qualified by the object's class name (UserControl). The class name can be used to distinguish properties and methods of the UserControl object from members of your ActiveX control which have the same names.
The Enabled property of the UserControl object acts much like the Enabled property of a form, enabling and disabling the UserControl and all of its constituent controls.
Note The purpose and importance of PropertyChanged are discussed in "Adding Properties to Controls," later in this chapter.
In order for your Enabled property to work correctly, you need to assign it the Enabled procedure ID. Procedure IDs are discussed in "Properties You Should Provide," later in this chapter.
To assign the procedure ID for the Enabled property
When you give your Enabled property the correct procedure ID, the container's Extender object shadows it with its own Enabled property; when the user sets the extender property, the container sets your Enabled property.
The reason for this odd arrangement is to ensure consistent Windows behavior. When a form is disabled, it's supposed to disable all of its controls, but the controls are supposed to continue to paint themselves as if they were enabled.
A Visual Basic form conforms to this behavior by tricking its controls. It sets the Extender object's Enabled property to False for all of its controls, without calling the Enabled properties of the controls. The controls think they're enabled, and paint themselves so, but in code they appear to be disabled.
If your control has an Enabled property without the Enabled procedure ID, it will remain enabled in code while all the controls around it are disabled. You can see this by putting a command button and a control of your own on a form, and adding the following code:
Private Sub Command1_Click()
Form1.Enabled = False
Debug.Print Command1.Enabled
Debug.Print MyControl1.Enabled
End Sub
Run the program before and after assigning the Enabled procedure ID to your control's Enabled property. In the first case, you'll see that the command button's Enabled property returns False, while your control's Enabled property returns True. After the procedure ID is assigned, both controls will return False.
You should avoid setting the UserControl's Enabled property, except in your control's Enabled property. The reason for this is that the container is responsible for enabling and disabling the controls it contains. It's rude for a control to tamper with properties the user is supposedly in control of.
When you author a user-drawn control, you have to provide your own representation of your control's disabled state. If you have implemented an Enabled property as shown above, you can determine when you need to do this by testing the value of UserControl.Enabled in the UserControl_Paint event procedure.
For More Information See "User-Drawn Controls," later in this chapter.