I teach Visual Basic programming for a living. Many times, I have been hired to teach "Introduction to Visual Basic" to students who have already taken a course by that name. Why? Because too many of the Visual Basic courses out there teach students how to "use" the Visual Basic development environment, not how to actually write Windows applications in Visual Basic!
There is a world of difference between the two. In the first case, students spend a day or two or three writing, in effect, calculator programs. Now, that's quite an accomplishment—if you happen to need a calculator—however, Windows already comes with one. Consider all that goes into a far more complicated application, one that is considered a simple one: Notepad.
When you open Notepad, it creates an initial, blank "document" for you. If you click the File..Save menu command, it behaves like the File..Save As command: it brings up the standard File Open dialog box, since your document has not yet received an actual file name. However, once you have saved a document, from then on File..Save does do a quiet save, because it knows the name of the file. File..Save As still brings up the File Open dialog, even when the document has a file name assigned to it.
In other words, File..Save sometimes behaves like File..Save As before storing the data on the hard disk; and File..Save As has to do the same job as File..Save, once the file has a name.
This is actually a fairly complex bit of behavior; and, remember, nearly every Windows application features it. How can you implement this in Visual Basic? Those three-day classes can't tell you.
Here's another example: Run any MDI (multiple document interface) application, such as Microsoft Word. Note that, after opening a document, you can use the Window..New command to create a duplicate window into the same document you were previously viewing. You can then arrange the two windows so both are visible at once. Now, type into one of them. Changes you make are instantly reflected in the other window...and this would be true even if you had a dozen, or a hundred, additional windows. This interplay of components could be quite daunting to implement if you didn't know how...and those three-day classes don't begin to cover anything like this. Yet, any MDI application you write must include this feature, or it isn't truly an MDI-compliant application.
That's why my Visual Basic classes are given in five days. That gives us enough time to learn, not only Visual Basic syntax and how to use the development environment, but also how to write a real Visual Basic application.
But, there's only one of me, and I won't live long enough to teach everyone in the world in person. Therefore, I am making my Visual Basic knowledge available via this Web site; I will add to it as time permits, and, hopefully, it will be of assistance to those who need to write real Windows applications, and not just calculators.
The modules listed below, through "Objects", cover the pre-requisites for my Accelerated Visual Basic course.
Working with CPUs A Little Visual Basic History Working with the IDE Working with Projects Working with Modules Working with Forms Working with Colors Working with Controls Working with Events Working with Objects Working with Applications