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 are 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.
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.
Let's see if we can tie all this together now.
> 1.Great programmers must be coding experts
> 2.Great programmers understand that there are many approaches to a problem
> 3.Great programmers work efficiently
> 4.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.
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.
Visual Basic Language Grouping ChartBeginner'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 Reference!
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 percentage.
If you want to learn code, then you have to read the manual over and over till 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 that 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.
|
Integer |
1, 2, 3, ... with the largest value = 32767 |
|
Long |
Like integers, but with the largest value about 2E9 |
|
Single |
0.2, 5.7, 24.12 ... any number with a decimal |
|
Double |
Like Single, but with the largest value about 2E308 |
|
Strings |
Not numbers at all, but letters or special characters |
Here's the most important list of variable types you'll run across in VB:
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.
1.ASCII is just an abbreviation that refers to storing information as string data. Each letter or number has a value (for example, the letter 'a' has the ASCII value 95) that 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.
2. 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 character.
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:
1. 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.
> 2. 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:
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 labelled "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 your mouse!
Helpful Tip!
Visual Basic has some built in variables that 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. Now, consider across all the controls that there are hundreds 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-explanatory, 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 that can be applied. Get in the habit of using these built-in constants to avoid the hassle of memorizing the actual values themselves!