![]() |
![]() |
![]() |
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
![]() |
![]() |
To access the contents, click the chapter and section titles.
Visual Basic 6 Programming Blue Book: The Most Complete, Hands-On Resource for Writing Programs with Microsoft Visual Basic 6!
The way it works is simple. Begin by closing the ActiveX controls designer by clicking on the close button (the X) in its title bar. This puts the ActiveX control into run mode. The only sign of your ActiveX control now is the UserControl icon on the Toolbox (it is labeled in Figure 17.5). Next, make the test projects form active and double-click on the UserControl icon to place an instance of it on the form, as shown in Figure 17.5.
Look in the Properties window: The new control instance has been given a default name, FancyCmdButton1, and it has its own set of properties. Change the Name property to FCB1 (for the sake of brevity). To take the ActiveX control out of run mode and back into design mode, double-click on its name in the Project window. When the ActiveX control designer opens up again, youll see that the instance of the control on the test project form becomes hatched, indicating that the control is no longer active. This is shown in Figure 17.6. ActiveX Control EventsYoull discover one difference between ActiveX controls and standard executable programs: An ActiveX control has a defined behavior not only at execution (when it is executing within its container) but also at design time. To illustrate this, open the UserControls Resize procedure and add the following line to the existing code: Debug.Print Resize event Close the ActiveX control designer to run the ActiveX control. On the test project form, change the size of the FancyCmdButton control. Youll see by the messages displayed in the Immediate window that its Resize event procedure fires each time you resize the control, even though the test project is still in design mode. If you add a second instance of the FancyCmdButton control to the form, youll see that the Resize event fires then, too. Delete the second controlif you placed onebefore continuing.
Now lets take a look at some of the other events that occur during the life of an ActiveX control. When working with these events, you must understand the ephemeral nature of an ActiveX control. You may think that once an ActiveX control is placed on a form, thats it; the control is created and continues to exist as a component of the form from then on. Things are not so simple. When you place an ActiveX control on a Visual Basic form during program design, an instance of the control is created in memory. When you run the program, that instance is destroyed and a new runtime instance is created; it is this instance that will be in operation as the program executes. When you terminate the program to return to design mode, the runtime instance of the control is destroyed, and yet another instance is created and displayed on the form in the Visual Basic designer. As you can see, rather than having a single instance of the control remaining, three have actually been created and destroyed. Heres another situation. Suppose you have designed an ActiveX control in Visual Basic and created a test form. When you close the ActiveX designer and place an instance of the control on the test form, you create an instance (as described in the previous paragraph). If you then reopen the ActiveX designer, so that the control on the test form is displayed with hatching, the control instance is destroyed. When you close the ActiveX designer, a new instance of the control is created (and the control on the test form is displayed without hatching). If you place two or more instances of a control on a form, each instance undergoes its own creation-destruction-creation cycle. Its pretty complicated, isnt it? Youll feel more comfortable with it after a while, particularly after I present some programming techniques later in this chapter that assist you in keeping track of the creation and destruction of control instances. For now, what you should remember is that an ActiveX control has certain events that are triggered in response to control creation and destruction. Some of these events have to do with the controls propertiesa topic well be covering. For now, lets just look at the events without worrying about the details:
To get a handle on when these various control events occur, you can use the same technique that you used earlier for the Resize event procedure: Place a Debug.Print statement in each event procedure to print the appropriate message to the Immediate window. The code is shown in Listing 17.2. With this code in your ActiveX project, you can trace events as they occur during the lifetime of your ActiveX control. Listing 17.2 Using the Debug.Print statement to track the occurrence of events. Private Sub UserControl_Initialize() Debug.Print Initialize event End Sub Private Sub UserControl_InitProperties() Debug.Print InitProperties event End Sub Private Sub UserControl_Paint() Debug.Print Paint event End Sub Private Sub UserControl_ReadProperties(PropBag As PropertyBag) Debug.Print ReadProperties event End Sub Private Sub UserControl_Terminate() Debug.Print Terminate event End Sub Private Sub UserControl_WriteProperties(PropBag As PropertyBag) Debug.Print WriteProperties event End Sub Responding To EventsWhen dealing with ActiveX controls, you have to consider events occurring at three levels:
|
![]() |
Products | Contact Us | About Us | Privacy | Ad Info | Home
Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement. |