Visual Basic 6 Programming Blue Book: The Most Complete, Hands-On Resource for Writing Programs with Microsoft Visual Basic 6!:RAD, Baby
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




Kinds Of Objects
The universe of Visual Basic objects contains two main categories: forms, which are simply screen windows; and controls, which are placed on forms to provide functionality. Among the many different kinds of controls are text boxes, option buttons, and command buttons. A Visual Basic program consists of one or more forms; each form usually contains one or more controls. I say “usually” because it is possible (although not common) to do things with a blank form. A form can also contain a menu, just like the menus you find in other Windows programs. Visual Basic has a menu editor that makes menu design easy.
You can see that a large part of creating a Visual Basic program consists of working with objects. You must decide how many forms your program needs, as well as which controls to place on each form. The mechanics of creating the forms and placing controls is quite easy, as you’ll learn in the next chapter when you create your first Visual Basic program. The technique of visual interface design—painting your program’s screens—is one of the two landmark innovations that Visual Basic brought to programming. We’ll meet the other technique later in the chapter.
Many, but not all, Visual Basic objects have a visual interface, which is to say that they display on the screen when the program is running. Some objects do not display, but work behind the scenes to perform some task.
Properties
Each Visual Basic object has properties that determine its behavior and, if the object has a visual interface, appearance. For example, almost all visible objects have Top and Left properties, which specify the screen position of the upper-left corner of the object. Likewise, the Height and Width properties specify the size of the object. Each type of object has its own set of properties, often running to a couple dozen or more. While some properties (such as those just mentioned) are common to many or all objects, other more specialized properties are relevant to only one or, at most, a few types of objects.
Object properties play an important part in a Visual Basic program’s interactions with the user. For example, if the user has entered text in a Text Box control, the program can access that text via the control’s Text property. In a similar manner, by reading a Check Box control’s Value property, the program can determine whether the user has turned the corresponding program option on or off. Note that when I say the program, I am referring to the Basic code in the program—code that you write.
You can change object properties during program design (referred to as design-time). Properties can also be read and modified at runtime, while the program is executing (runtime). The ability to read and modify properties at runtime may sound trivial, but it plays an essential role in Visual Basic’s power. This flexibility permits a program to be self-modifying—to change its appearance and behavior in response to current conditions and user input. You’ll see plenty of examples of this throughout the book.
You’ll find that a significant portion of your Visual Basic programming time will be spent dealing with these properties, which is a good indication of their importance. We can think of properties as the edges, or skin, of objects. Our knowledge and control of an object is limited to the properties the object makes available to us. All sorts of complicated stuff may be going on inside an object, but we have no way of knowing about it. More importantly, we don’t want to know about it. We only need access to the object’s properties to make full use of its capabilities.
Methods
Most Visual Basic objects have one or more methods associated with them. A method can be thought of as a chunk of code that does something to, or with, the object. Instead of you having to write the code, however, it is an integral part of the object.
The methods that are available differ from object to object. For example, the Move method, which moves an object to a different location on screen, is available for most objects. In contrast, the Print method, which displays text on an object, is available only for forms and a few other objects where the display of text makes sense.
Events Make It Happen
The second major innovation that Visual Basic introduced is event-driven programming. (The first—in case you were dozing for the first part of the chapter—is the use of visual objects.) What are events, and how do they work? The first part of this question is easy. With a few exceptions, events are things the user does with the mouse or the keyboard while the program is running. In other words, event means user input. So far so good, and hardly surprising. But I can hear you saying, “Of course a program must respond to user input, so what’s the big deal?” The big deal is how a Visual Basic program responds to user input, and how easy it is for the programmer. The way that Visual Basic deals with user input is intimately tied in with the Windows operating system, so let’s start there.
Interacting With Windows
If you’ve used Windows at all and given just a little thought to how it works, you are probably already aware of the way that Windows handles user input, or events. (If Windows is a foreign entity to you, I’ll repeat my suggestion that you become familiar with it before continuing.) With rare exceptions, Windows is always responsive to events. Even if the currently active program is not responding, Windows itself is—whether you press Alt+Tab to switch to the next task, click on a button on the taskbar, or whatever, Windows detects the event. Of course, Windows does not respond to every user event; that would lead to chaos. To be completely accurate, I should say that Windows detects every event, but responds only to certain ones. How does this happen?
Hello, Western Union?
At the heart of Windows’ event-detection capabilities is its messaging architecture. In fact, messages play a vital role in just about everything Windows does, but we will limit ourselves to a basic look at messages and events.

Whenever Windows is running, Windows is running. Now this may seem like a nonsensical statement, but it serves to emphasize the intimate relationship between the Windows operating system and individual programs that are executing. Many (if not most) of what a program does is actually performed by Windows at the program’s request. Among these tasks is complete management of user input via the keyboard and mouse. When any mouse or keyboard event happens, Windows knows about it and dispatches a message identifying the event to Windows’ message queue. The message might say, in effect, “The mouse was clicked at screen coordinates such-and-such” or “the F5 key was pressed.” All programs that are running at the moment can receive the message. This includes application programs, as well as Windows’ own processes. The message is available to all programs, but only the one that is interested in the event will bother to “read” the message and respond. It’s sort of like a mother going to the front porch and yelling, “Herman, if you don’t get yourself home for dinner this instant, I’ll tan your behind!” All the kids in the neighborhood have access to the message, but only Herman will respond (at least if he knows what’s good for him).
Figure 1.1 shows a simplified diagram of the Windows messaging system. My account is simplified as well—the actual system is quite complex. You don’t need to understand all the details; it’s enough for you to grasp the basics of messaging.
Just remember that Windows does all the work of event detection, dispatching messages to identify each event that occurs. All your program needs to do is keep an eye on the message stream and latch on to the messages of interest. How is this accomplished? As you’ll see next, it’s ridiculously easy.

Figure 1.1  Windows is continually looking for events. When it detects one, it dispatches a message to the running programs, which can respond.




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.