Developing Real Imaginary Projects


The sample projects provided with this book are real in the sense that they exist on your disk. But most of them aren’t exactly typical real-world projects. Nevertheless, you might be interested in how I built them, and you certainly want to know how to use the resulting components.


The samples serve two purposes. Most of the client programs (with the exception of the wizards) aren’t particularly useful except to illustrate the techniques discussed. You might be able to cut and paste a few bits of code, but most of the reusable stuff is in the components, not in the client programs. You might find it interesting to load some samples and step through parts of the code—especially the parts I didn’t get around to explaining. But the components are the real point. I like to think of Hardcore Visual Basic as some components with an accompanying book, not the other way around.


In order to make the components more useful, I provide them in two forms: debug and release. If you write programs that use the components, you can use the debug versions during development. These versions will give you some output errors and asserts if you give parameters that are legal to Visual Basic but that violate the definition of the component. When you’re ready to create your release candidate, you can build with the release versions.


You might want to step through code while reading about it in the book. You have two choices: you can debug the client programs with the compiled components, or you can debug the components through a test client. For example, to debug Edwina the Editor from Chapter 9 as a client program, load Edwina­.VBP. By default, Edwina.VBP will use the debug versions of VBCore.DLL and other components. To switch between debug and release components, you can run the batch files TODEBUG.BAT and TORELEASE.BAT. This will register the debug or release version of the component.


To debug the XEditor control, the XDropStack control, or the VBCore library through Edwina, load Edwina.VBG. This allows you to step into any component. This is a good time to repeat my earlier warning. It’s tempting to just fix any bugs you might find in my code and rebuild my components. Please don’t. The last thing I need is multiple versions of my components floating around. You can put any of my code (including whole classes and controls) in your own components as long as you change the names and the GUIDs.


Better Basic Through Subclassing


“If I had designed Visual Basic, I could have made that procedure better.”


Well, quit complaining and do something about it. You don’t have to accept the Visual Basic run-time library. You can replace procedures with your own versions, or you can enhance procedures by subclassing them. The BETTER.BAS module fixes some of the Visual Basic procedures I didn’t like. For example, the Timer function isn’t accurate enough for my taste, so I replaced it:

Function Timer() As Single
    Static secFreq As Currency, secStart As Currency
    If secFreq = 0 Then QueryPerformanceFrequency secFreq
    QueryPerformanceCounter secStart
    If secFreq Then Timer = secStart / secFreq
    ‘ Else Timer = 0 if no high resolution timer
End Function

The Basic version is apparently based on the system time and date features. It is nominally accurate to a hundredth of a second, but in practice it appears to be even less precise. The QueryPerformanceCounter API function gets whatever accuracy your machine is willing to return—normally better than a millisecond.


The problem with the better version of Timer is that it returns what most Basic programmers want (an accurate time count) rather than what the documentation says (seconds since midnight). Normally, you use Timer to measure the difference between two times. You don’t care whether the unit of time returned is seconds since midnight, seconds since the last boot, or seconds since the first MITS Altair was switched on. If for some reason you really need to know the number of seconds since midnight, you can specify the original Timer: