Click here to advertise your product to over 25,000 VB programmers
| ||
|
Dale's Workbench
by Dale Shaw |
| This article assumes you're familiar with: |
|
Visual Basic |
You can read this article in Spanish
The next couple of columns will discuss the creation of VB4 classes, using these classes within your application and, finally, shipping the newly created class / object as an OLE server DLL or EXE. Along the way we will dive into some other related topics, give some background information and some links to places to find more.
Now, these columns are going to take a 'tutorial' style so if you are the type that just wants to get to work ASAP then I will try and provide you with some links to skip ahead! I will also try to keep it interesting (but no promises!). I also want to throw in as much ready to run code as possible to make things easy.
I am going to base the next few columns around a sample utility application I have designed but I will keep it under wraps till next month! I wouldn't want to distract you from the theory we need to cover up-front…..
These columns are broken up into a few different sections so that you can pick the level that suits you, skipping the stuff you may already know. If you are relatively new to VB then maybe you should start at the beginning:
This month . . . .
Part 1 - Visual Basic Variable Scoping
Coming months . . . .
Part 2 - Visual Basic Procedure Scoping
Part 3 - Defining you own Form Properties and Methods
Part 4 - Creating a Class library
Part 5 - Using your Class library within your app
I welcome feedback and hope this series of articles gives you an insight into VB classes, OLE and controls.
Part 1. - Visual Basic Variable Scoping.
Variables in VB are nothing more than named storage locations, somewhere we store information whilst our program is running. There are many different types of variables with the most common being string and numeric (which in itself has many types).
Before we get too heavily involved in scoping, lets just talk about variable declaration. Should I pre-declare my variables? Take a look at this code:
The logic behind the above code is simple: it creates a variable called TotalDue and stores 100 as it's initial value. If the product code is greater than 1000 then we want to increase TotalDue by 10% however due to a typo this does not happen. What happens above is that the third line creates a NEW variable called TotalDur which the rest of our program happily ignores. A simple typing mistake turns out to cost us (or our customer) money.
How do we avoid this? By declaring our variables using the DIM, PUBLIC and PRIVATE keywords. On their own, however, they will not eliminate the above problem. When working in VB I STRONGLY encourage developers to set the 'Require Variable Declaration' option by selecting the Tools menu and selecting the Options menu item:
One important thing to note is that checking this box will only affect forms and other modules created from this point on. Existing forms etc will still not require declaration.
Now what is scoping?
Scoping could also be termed visibility because what we are defining is "For how long will I be able to see this variable?"
Take this code for example:
Once again, pretty simple code but the key is the Dim statement. What Dim does is tell VB to reserve a certain amount of space. In this case we have specified a Long so it reserves enough space to store whole numbers (no decimal place) up to about 2 billion or so.
By declaring the variable in this way we are forcing VB to do a number of nice things the simplest of which is that it knows the name of the variable. This means that when we go to run our code VB can check that all variable references are correct - that they do, in fact, exist.
Now, Answer is defined as Long so it is created the moment the code here executes and it has a default value assigned to it - in this case ZERO. The next line of code takes the contents of Text1 and Text2, multiplies them then stores the result in the Answer variable. (Several things could go wrong at this point like Text1 and Text2 not containing numbers or the result could exceed the storage space for our Long: like 100000 * 100000. We will deal with error handling later on.)
Once the value is stored in Answer it is then taken and stored in Text3.
The important part is: What happens to Answer as the code progresses?
Answer was declared within this procedure (the cmdMultiply Click event in this case) so it's scope or visibility is declared as being local to this procedure. In other words, as soon as the End Sub line is executed Answer ceases to exist. It cannot be referenced by any other code outside this procedure.
What if we do need to have variables that we access across multiple pieces of code? Maybe it's something like the company name, discount level or what customer we are currently working with. The key here is to widen the variable's scope.
We can do this by declaring the variable as part of the General Declarations section of the module. (What's a module? For now, consider a form (a .FRM file) or standard module (a .BAS file) as the only module we deal with. Soon we will add classes (.CLS files) as well.) Take a look at this code:
First thing to notice is that this is part of a form. Anything declared as part of a form (both variables and procedures - see next month!) is by default PRIVATE. What this means is that the variable is available to ANY code within this module. As this is a form this will mean that any event within this code can store or retrieve strings from this memory location. As this variable has been Dimmed (by default) as private to the form it cannot be referenced by any code outside this form.
Second thing to notice is the Option Explicit: require variable declaration.
OK, so we have a variable we want to access across the entire application. The way to do this is …. Declare it Public! For example:
CustomerNumber has been declared as Public and this has been done in the general declarations section of a standard (.BAS) module. The implications of this are that we will now have access to this variable from ANYWHERE in the application - from the time it starts to the time it finishes. Note Status has been declared as Private - once again making it accessible only to code within this file.
Public variables declared in the general declarations section of a form behave slightly differently to Public variables defined as part of a BAS module.
A public variable in a form becomes a property of the form, meaning that it is globally accessible within the application but must be referenced by adding the form name in front of the variable name:
Form1.CustomerName="ABC Incorporated"
Debug.Print Form1.CustomerName
The main difference is the lifetime of a Public form variable. A public in a BAS module is available throughout the life of the application but a form level Public variable may be removed from memory and later re-initialised to a different value. For example:
Next month we will discuss procedure scoping and then move onto creating class libraries.
Dale
About the Author
Dale is a consultant and trainer for LAN Technologies, a New Zealand based software development firm.
Dale Shaw
LAN Technologies (New Zealand)
| ||
