Visual Basic 6 Programming Blue Book: The Most Complete, Hands-On Resource for Writing Programs with Microsoft Visual Basic 6!:ActiveX Controls
function GetCookie (name) { var arg = name + "="; var alen = arg.length; var clen = document.cookie.length; var i = 0; while (i < clen) { var j = i + alen; if (document.cookie.substring(i, j) == arg) { var end = document.cookie.indexOf (";", j); if (end == -1) end = document.cookie.length; return unescape(document.cookie.substring(j, end)); } i = document.cookie.indexOf(" ", i) + 1; if (i == 0) break; } return null; } var m1=''; var gifstr=GetCookie("UsrType"); if((gifstr!=0 ) && (gifstr!=null)) { m2=gifstr; } document.write(m1+m2+m3);            Keyword Title Author ISBN Publisher Imprint Brief Full  Advanced      Search  Search Tips Please Select ----------- Components Content Mgt Certification Databases Enterprise Mgt Fun/Games Groupware Hardware IBM Redbooks Intranet Dev Middleware Multimedia Networks OS Prod Apps Programming Security UI Web Services Webmaster Y2K ----------- New Titles ----------- Free Archive 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! (Publisher: The Coriolis Group) Author(s): Peter G. Aitken ISBN: 1576102815 Publication Date: 08/01/98 function isIE4() { return( navigator.appName.indexOf("Microsoft") != -1 && (navigator.appVersion.charAt(0)=='4') ); } function bookMarkit() { var url="http://www.itknowledge.com/PSUser/EWBookMarks.html?url="+window.location+"&isbn=0"; parent.location.href=url; //var win = window.open(url,"myitk"); //if(!isIE4()) // win.focus(); } Search this book:  














Previous
Table of Contents
Next




The way it works is simple. Begin by closing the ActiveX control’s 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 project’s form active and double-click on the UserControl icon to place an instance of it on the form, as shown in Figure 17.5.


Figure 17.5  The test project form after placing an instance of the UserControl on it.

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, you’ll 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 Events
You’ll 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 UserControl’s 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. You’ll 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, you’ll see that the Resize event fires then, too. Delete the second control—if you placed one—before continuing.

Figure 17.6  When the ActiveX control is placed back in design mode, the instance on the test project form displays a hatch pattern.

Now let’s 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, that’s 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.
Here’s 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.
It’s pretty complicated, isn’t it? You’ll 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 control’s properties—a topic we’ll be covering. For now, let’s just look at the events without worrying about the details:

•  Initialize—Occurs each and every time an instance of the control is created. It is always the first event that occurs for the control.
•  InitProperties—Occurs only when the control is placed on a form—in other words, the first time an instance is created. You can use this event procedure to set a control’s initial values.
•  ReadProperties—Occurs the second and subsequent times an instance of a control is created. In other words, this event occurs every time a control instance is created except the first time (when InitProperties occurs instead).
•  Resize—Occurs every time a control instance is created and every time its size is changed, either by the programmer in design mode or by code during program execution.
•  Paint—Occurs whenever the control’s container tells the control to redraw itself. If you are creating your control’s visual appearance with drawing methods, the code should go in this event procedure.
•  WriteProperties—Occurs during design time when an instance of the control is destroyed and at least one of its properties has been changed.
•  Terminate—The last event to occur when a control instance is destroyed.

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 Events
When dealing with ActiveX controls, you have to consider events occurring at three levels:


•  The constituent controls used to create the ActiveX control, such as the Shape and Label controls in the demonstration project, may need to respond to events.
•  The ActiveX control may need to respond internally to events, such as the user clicking on the control.
•  The container object may need to respond to events that occur to the ActiveX control.





Previous
Table of Contents
Next






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.