In this section I'll cover the topic of coding - the use of the Visual
Basic language. As part of this section I'll try to show you which elements
of the language you need to know the most, and which elements work together.
Even more than you saw with some of the intrinsic controls, there are groups
of the VB language which are almost always used together because they cover
different aspects of a problem.
It's worth noting that when managers talk about programmers, one of the
common metrics used to describe performance is "lines of code per month".
There's all kinds of debate about how good a metric this is, but the fact is
that the metric is used!
It's not that you don't get credit for novel algorithms, or that you won't
be a hero to fellow programmers when they see how you solved a problem with
10 lines of code that took them 100. You'll get that credit (and mental
satisfaction, too!) but looking at the big picture it's clear that the
volume of code you can crank out will be the visible result of your efforts!
Let's walk again through the elements of writing a VB application. The
percentages at the right are an estimate of how much time a programmer
might spend on the various phases of the program. For short programs, a
greater percentage would be spent on the concept and user interface phases.
For larger programs, more time will likely be spent on the later phases.
However, in either case you can see that the coding section is one of the
key areas in which a programmer will be spending his time.
- Concept / Requirements Definition (10%)
- User Interface Design (20%)
- Coding (40%)
- Test & Debug (20%)
- Customer Acceptance / Evaluation (10%)
Get the picture? If you want to be a great programmer, you have to
know how to code!
There's another aspect to coding that you need to be aware of, but it's a
little harder to explain. In the electronics manufacturing business there's
a saying that 90% of the cost of a product is determined in the design. Can
you see the link? Writing a program is essentially a design task, aimed at
solving a problem. Like most things, there are many design approaches for
every problem. Some solve the problem by grinding out an answer. Some are
very elegant. Others are so complex that even the designer has a hard time
keeping up with the convolutions of the approach.
Remember that in my Training/Advice I
harped on the idea that a programmer's job was to economically provide the
result for which he is being paid. A customer will be more impressed by
a job done on time, on budget and which meets spec than he will be for a project
with overruns because of bells and whistles (or unusual code) which do not
improve the utility of the application to him or his employees.
You'll get this kind of philosophy to programming throughout this tutorial.
Let's see if we can tie all this together now.
- Great programmers must be coding experts
- Great programmers understand that there are many approaches to a problem
- Great programmers work efficiently. Remember my
As I go through the rest of the tutorial I'll try to show how these principals
can be applied to real life decisions and solutions.
Language Grouping - According to Beene
My overriding approach to learning is take what I read and try to piece it
together with everything else I've learned. I think of all knowledge as
one big puzzle and it's important to know where each piece of information
goes in the puzzle in order to understand it's importance. In programming,
knowledge is certainly a tool and as my daddy used to say, "It's the
poor carpenter who blames his tool!".
The immediate value of this pearl of wisdom is shown in the following chart.
Beginner's who read through the Microsoft manuals, particularly the Language
Reference manual, are often intimidated by how darn many commands they find.
An alphabetical listing is simply no help in getting your arms around the
problem. Back in the DOS days, several of the BASIC manuals groups
commands much like what you see in the table above. This one is one that
I did myself, while reading through the entire Microsoft VB Language
The value of such a grouping is twofold. If I had it to start with then I
could have "bitten" off commands in small chunks. The small doses would
consist of commands which act together to let me perform categories of
tasks (file I/O, user input, loops, string manipulation, etc.).
Secondly, by creating my own grouping, I forced myself to think about
the code and to understand not only what the command can do, but how it
can be used with other commands to get a job done!
This brings me to another philosophical point. You noticed that I mentioned
having read the entire Language Reference? On my Beginner's page
you may be noted that I also have read the Programmer's Guide front to back
not once, but three times? I am a staunch believer that reading material
can only be absorbed little by little. You read something once and you get 70%
of it. Read it again and you get up to 90%. Third time brings you up to
95%. Better yet, write your own tutorial and you'll get some of that last
If you want to learn code, then you have to read the manual over and
over til it makes sense to you. Each time you learn something, you're
better able to learn something else. That's why rereading a manual is so
valuable. The skills you pick up in the first reading make it easier to
understand the parts you didn't understand the first time. I encourage
you to read, read, read and while you're doing it, take notes and later
summarize what you've learned. It sounds tedious, but then coding is
not exactly all glitter either!
All of you have seen the acronym RTFM, right? Well the popularity of this
phrase just backs up what I've been saying. You'll get no sympathy from me
for misunderstanding a topic unless you can show me where you studied the
topic. Of course, it's okay to not understand the manual's explanation of
a topic (Microsoft's manual are good, but they are definitely not great!)
but you owe it to the person you're asking questions of to have done the leg
work yourself before drawing on their experience to help you out.
I know you have been getting anxious to get to the coding part which
I keep referring to, but there's one more lesson you need before we get
there. The lesson is about variables. Simply, a variable is a name you
use in your program which refers to a value. You've probably already seen
variable names like x, or i, or name, or .....
You've probably already heard that values can be represented in many ways,
such as integers, floating point values, strings, objects, etc.
Here's the most important list of variable types you'll run across in VB:
||1, 2, 3, ... with the largest value = 32767
||Like integers, but with the largest value about 2E9
||0.2, 5.7, 24.12 ... any number with a decimal
||Like Single, but with the largest value about 2E308
||Not numbers at all, but letters or special characters
This isn't the whole list, but it's definitely the ones you'll use 99% of
the time in your applications. I'll bring up the others as we need them
in the tutorial.
This list is not just an exercise in useless knowledge. Later on
you'll see how the use of a particular variable type can be of use in
speeding up your program or of how using the wrong variable type can
actually result in a wrong answer in some calculations! What you don't
know can really hurt you!
Often, books on VB don't cover this topic until much later in the book.
I'm covering it early because it influences how I've grouped the VB language
into the chart above.
A fundamental thing to understand is that computer files are usually stored
in two basic ways, ASCII and binary.
- ASCII is just an abbreviation which refers to storing information
as string data. Each letter or number has a value (for example,
the letter 'a' has the ASCII value 95) which you can find in VB Help
by searching on ASCII. The value 12 is stored as a two character
string, '1' and '2'. This takes two bytes of hard disk space.
- Binary describes a way of storing data more efficiently than ASCII.
The value 12 would be stored as a single byte value represented
by the binary string 00001100. This approach holds for all numbers
although larger numbers may take more than a byte of storage. Strings
cannot be stored this way and are always stored as one byte per
Visual Basic has commands which can read or store in both storage methods.
The storage method you use can make a big difference in how simple the code
can be in your application. I won't cover all the details now, but will
bring it up as needed in the tutorial. For now, here's the summary:
- ASCII storage is most useful for storing strings. When both
numbers and strings are stored, ASCII is normally used. VB commands
for ASCII file access are usually the least complex I/O commands, but
are not as flexible as binary file I/O commands.
- Binary storage is more useful for storing numbers. VB commands let
you read one or more bytes of binary data at a time and if provides
more flexibility in moving around through the file.
There are, of course, other schemes for storing data. Many programs such
as Word, Excel, and PowerPoint have their own storage schemes. This is
also true of database program files such as those created by Access or
dBase. This tutorial won't discuss proprietary formats except to note
that they exist.
VB has commands which allow you to print information, either to the computer
screen or to a printer. For the printer, VB creates
an empty "canvas" to which your commands write, then dumps the "canvas"
contents to the printer on demand or at the conclusion of a program.
For me, the single most tedious aspect of coding is that of printing reports.
I strongly advise that whenever possible, that you make use of
reporting tools such as the Crystal Reports control that comes with Visual
Basic. Crystal Reports provides a very fast method of creating printed
reports against data
contained within Access databases, which is native database format supported
by Visual Basic.
One fundamental aspect of VB which will become second nature to you is the
idea of procedures.
When we talk about VB commands, such as "Print", or "Open", we are talking
about a command which tells VB to run a section of code which performs
the Print or Open function. The code is contained in the various VB files
that were installed on your machine, such as DLL files that get distributed
with your applications.
With VB, like most languages, you can create your own "commands" but we
call them procedures instead. The two types of procedures VB supports are
called Subroutines and Functions.
- Functions: These procedures are a section of code which is run
when the Function is called, and a single value is returned to the calling
line. For example, when you use the square root function in VB:
x = SQR(25)
This is a VB function called SQR. It passes the value 25 to the function
and the function returns the square root and places it into x.
- Subroutines: These procedures are just like a Function, but no
value is returned.
It's important to note that procedure calls include a list of values (or
variables) which are passed to the procedure. The procedure is allowed
to change those variables when it is executed - but you make the decision
by the choice of your code within the procedure.
Okay, it's coding time!
Okay, let's begin to pick apart the subject of coding. You'll remember that
I described coding as something you put into an event procedure that VB
will execute when the event occurs? Well, that's true but you can also
add code to your application which is not contained in an event procedure,
but which must be called from within those event procedures.
Here's how it works. If you double-click on an object in the IDE you'll be
presented with the code window for that object. The upper left dropdown
list shows the list of objects in your application and the upper right list
shows the events that each object supports! Its an excellent way to explore
the events your objects can support. If an event has had code added to it,
the event list make the event title bold.
If you look at the top of the left dropdown list, you'll see a listing that
is labeled "General". Remember those Function or Sub procedures we discussed
earlier? Well you'll find all of them in this "General" section. VB
automatically collects all of the user-defined function and sub procedures
into this one area.
So, back to a higher level of discussion: When you enter code, you first
think to put it in the events of your project objects. If you have special
function or sub procedures to write (mostly because it will be used in
multiple locations throughout your application) then you create a Sub or
Function to put the code. Sub/Function procedures work identically except
VB controls when an object event procedure is executed, whereas the code
you write in the event procedures can specifically call out for your custom
Sub/Functions to be executed.
By the way, you can also cause an object's event procedure to be executed at
any time. For example, if you have a button (Command1), then it's click
procedure is command1_click. If you type this procedure name in as a line of
code, then it will execute, just as though you have clicked the button with
Visual Basic has some built in variables which can make your code very easy
to read, and more importantly, are much easier to remember than the actual
value of the variable. Here's how it works:
Suppose you want to set the .CHECKED property of a checkbox to its checked
state? If you look into HELP you'll see that you must see the .CHECKED
property to a value of "2" for it to be checked. Easy enough? Well,
consider across all the controls that there are hundres of properties to
remember. VB comes to the rescue with built-in variables. In our example,
you could set the .CHECKED property to the built-in variable VBCHECKED, which
VB will recognize as a "2".
As you would guess, there is also a VBUNCHECKED. Both of these are visually
self-explantory, whereas if you used an integer (2 or 1,in this case) you
might trouble figuring our which state the code is intended to create.
VB has a lot of these easy-to-remember constants. When you read HELP for
the syntax of a command/function, you will find the list of built-in
constants which can be applied. Get in the habit of using these
built-in constants to avoid the hassle of memorizing the actual values