Managing a custom ActiveX control's events and behavior is a bit more complex than
for most other objects, such as standard controls and Forms or other types of ActiveX components.
This complexity is due to the fact that you must keep two levels of behavior
in mind for your control rather than just knowing the usual runtime behavior. In other words,
you must also manage the behavior and features of an ActiveX control when another programmer
uses it at design time in an application.
Most of the increased complexity in a custom ActiveX control has to do with the
management of the contents of its properties as the control moves from abstract definition
to being an instantiated object in a VB project and from there to life in a running VB application.
Control Authors and Developers
In order for your ActiveX control to provide its services to end users, some intermediate
programmer must put the control into his or her application. As the author of an ActiveX
control, therefore, you must specify design-time features of your control as well as runtime
features. The ultimate user of the runtime features is that archetypal, shadowy being we programmers
have come to know, love, and fear as the end user.
The user of the design-time features will be another programmer. In this chapter
we will call you, the programmer creating the ActiveX control, the ActiveX control author.
In this chapter, we will refer to the programmer using the ActiveX control in an application
as the developer.
IMPORTANT - Who Is the "User" of an ActiveX Control?:
Much of the documentation on ActiveX custom controls employs the word
"user" loosely, sometimes meaning the end user of the application where your control
is sited and, at other times, meaning the developer who is programming with your