Up to this point, we've seen that you can implement custom control methods
and events in more or less the same way as you implement methods and events for other ActiveX
object classes.
The situation for custom control properties is more complex however. This is
because, as the author of a custom control, you must manage the persistence of property
values as instances of a control are created and destroyed at design time.
You must do a little more work than for events and methods in order to get
custom control properties to behave properly.
As we've already mentioned several times, this is because instances of
your control are created and destroyed numerous times during the development life cycle. For
more detail on the actual activities that cause such carnage, see the accompanying sidebar.
Events In A Control's Lifetime That Affect Properties
During the developer's design, test, compile, and redesign cycle, instances
of your control will be created, then placed or sited on their container object (a
Form, PictureBox, or other object capable of holding controls), and destroyed—not
just once, but many times. The reason for all this activity is that an instance of your control
must be destroyed and created whenever the control and its container move between the various possible
degrees of being and non-being during the phases of development.
Here is a list of the occasions when instances of a control would be created
and destroyed:
-
Created-. The developer creates an instance of the control from
the toolbox and sites it on its container.
-
Destroyed-. The developer closes the Design window with the control's
container.
Created-. The developer reopens the Design window with the control's
container.
Destroyed-. The developer begins to run the application in the VB
environment, which temporarily destroys design-time instances of objects (including
your control).
Created-. The control's container loads into memory and sites the
control as the application runs.
-
Destroyed-. The control's container is destroyed as the application
runs.
-
Destroyed-. The control's container is destroyed because the application
stops running.
-
Created-. The application has stopped running and VB returns to the
design environment thus resiting your control (provided the design-time environment currently
includes a sited instance of the control).
-
Destroyed-. The developer closes the project or closes VB.
Created. The developer opens the project provided that the current
view of the project includes an instance of the control's container.
You may wonder why it's important for you to know about the timing of
the creation and destruction of ActiveX controls. After all, we can manipulate standard controls
and other objects without having to know such details.
As control author, you must be able to react to control creation, destruction,
and change. It's up to the control's author to determine when and how long changes
to control properties will persist. As you probably know, control properties get stored with a form's
other information in the form's .frm file. While a developer works on an application in
the VB design environment, the copy of the form (and all its associated information) that resides
in memory gets destroyed and re-created as described in the above list. It is the responsibility
of each control to save and retrieve information about its own state (including any changes to
property values) during these times.
You can implement this management of your custom ActiveX control's properties
by programming the event procedures of various events of the UserControl
object and by taking certain measures whenever a property might change, as discussed
in the following subsections.
In the following sections, we discuss the bare minimum you need to do in order
to get custom control properties to function adequately.
We first discuss how to create a new custom property (this is the same as for
other object classes in VB) then we discuss how to initialize properties in the
InitProperties event procedure. Finally, we cover the particulars of how to make properties
persistent by programming the UserControl's Property
Bag object in several key UserControl events.
Defining Properties with Get/Let/Set Procedures
or Public Variables
