First there’s the application developer, Adam App. Adam’s responsibility is to write the Hexer application. He uses the HexTool DLL library and the HexIt control but doesn’t have development responsibility for either of them. When he encounters a bug, he reports it to the library developer, Linda Library, or to the control developer, Connie Control.
The three developers are served by Barb Buildmaster, whose job is to coordinate regular builds of all the Radices Unlimited programs and components. She tries to make daily debug builds and weekly release builds. A debug build contains asserts and log messages that provide testers and developers with useful information when they encounter problems. Barb uses the debug system I described in “Examining Code” in Chapter 1. Release builds are pure code with no debugging information. Often, one part of the project has bugs that prevent its being built on schedule, so Barb tries to make each build independent of the others. That way, one bug won’t necessarily bring down the whole project.
Tim Test is the tester for HexTool. Tom Test works on HexIt. Tadd Test works on Hexer. Tim and Tom have to write hundreds of test programs that validate HexTool.DLL and HexIt.OCX. They don’t have access to the component source, working instead with the compiled debug components. Tadd never sees any source, just the completed debug version of Hexer.EXE. He tests it interactively, in batch mode, and with a scripting program that feeds in keystroke macros. The Test triplets also run test scripts on release builds to make sure debug code isn’t masking bugs, and they sometimes use release builds for performance testing. When early beta versions start going out, beta customers will get debug builds. Late in the cycle, they’ll switch to release builds. In the last few weeks before release, everybody uses the release versions to make sure they’re seeing exactly what customers see.
It’s easy to work on a project that contains several ActiveX controls and DLL components—if you’re the only person working on the project. Just use a project group (the VBG file) containing the program project and the component projects (the VBP files). When you want to build the program, select Make Project Group from the File menu. You’ll end up with an EXE that uses each of the compiled components. The problem is, this ties all your components together. You’ll end up rebuilding everything even if only one component is out of date. And if several client programs depend on the same components, you’ll have to rebuild each component for each client project group.
Real-world development requires a more flexible system, and through trial and error, Radices Unlimited has come up with one. Figure 5-2 shows how the parts fit together.
Barb uses independent project files to build each part of the project. She also has responsibility for building all the other programs that depend on HexTool.DLL and HexIt.OCX. Barb uses whatever project files she finds under source control without checking the files out. She has, however, laid down rules for checking in projects. Basically, no file is checked in unless it is complete and stable at the current level. In other words, the developers had better not break the build. Although Hexer might look messy to you, it’s one of the simpler projects Barb works with. Octalizer, for example, consists of one application file, two ActiveX DLL components, one ActiveX EXE component, and four ActiveX controls. Many of the parts have dependencies on each other. Barb builds all the parts from the command line with a make program and a make file—just like in the old days when she built C projects under UNIX.
Figure 5-2. Radices Unlimited Hexer Builds.
Adam works in the IDE with the same Hexer.VBP file that Barb uses. Since Hexer is his responsibility, he owns Hexer.VBP and is the only one who has authority to modify the project file or the modules in it. Adam can look at the source for HexTool and HexIt, but he has no authority to check them out and modify them without express permission from their owners.
Linda does most of her HexTool development using her own HexTest application. She has a HexTest.VBG that points to HexTest.VBP and HexTool.VBP. HexTest is a private tool and no one else has access to it, although Linda sometimes informally shares test code with Tim, the library tester. Linda sometimes uses Hexer to track down bugs reported by Adam. In order to debug HexTool with Hexer, she has to have Hexer source code, but she doesn’t normally check it out of source control. She just reports any bugs she encounters to Adam.
The official Hexer.VBP references HexTool.DLL, however, Linda needs to use HexTool.VBP. Fortunately, Linda can get Hexer.VBP to ignore its reference to HexTool.DLL and instead use HexTool.VBP. She does this by using a private project group, which we’ll call HexerL.VBG (although Linda calls it Hexer.VBG). Linda’s VBG references Hexer.VBP and HexTool.VBP but not HexIt.VBP because Linda always wants to use the OCX rather than the source.
The VBG file controls whether a client project references the compiled component or the component source. When you compile a component for the first time from within a client VBG, Visual Basic will automatically switch the reference from the component VBP file to the compiled DLL or OCX file (assuming that Project or Binary compatibility is set on the component). You can confirm this by examining the client VBP file with a text editor. But as long as you use the component from a VBG, the References dialog box will show a connection to the component VBP. When you switch to the client VBP, the references will show the real reference to the compiled component. Don’t look for an explanation of this in Visual Basic documentation. I discovered this feature by accident after many hours of trying to come up with a hack that would fake the same behavior. The person who wrote the documentation was as surprised as I was when I described it to him. So here’s a gentle reminder from all of us hardcore technical writers to all you hardcore programmers. It doesn’t matter how &%$#(*& clever your *%@&$ features are if you %*@#+^*& don’t tell us about them, ^%~$*##!
Connie Control has a few extra maintenance problems. At one point, the HexIt control used a few functions from the HexTool library, but the problems of having Hexer and Hexit both depend on HexTool proved to be a nightmare. Fortunately, Connie (like all employees of Radices Unlimited) has a copy of Hardcore Visual Basic. She now uses the Global Wizard described earlier in this chapter to generate standard modules and private classes from the source modules in HexTool. It’s not the preferred method of reuse, but it works despite some inconvenience. Besides, HexIt will eventually be released as an independent tool and customers won’t want an extra DLL.
Like Linda, Connie uses a private test program, Hexercize, for most of her development. She also uses Hexer for real-world testing and when responding to bugs. She has a private project group (HexerC.VBG) that references Hexer.VBP and HexIt.VBP but not HexTool.VBP. Notice that Connie’s situation is a little more complicated than Linda’s because HexIt.OCX is referenced not only from Hexer.VBP but also from Hexer.FRM. Fortunately, Visual Basic knows that when a VBG is used, it should ignore all references to the compiled component and use the component VBP instead.