Forgotten Tools
This article appeared in the July 1998 edition of EXE,
and was the first of the regular columns. The primary focus of this article
specifically relates to Visual Basic 5.
This is the start of a regular column that is aimed at the
Visual Basic developer. The decision to provide regular VB coverage in a
magazine that by its own definition is not oriented solely towards any specific
platform is indicative of the huge support that the language commands within
the development community. When the product first shipped in 1991 it was seen
very much as a prototyping tool – a means of throwing forms together
quickly to show end-users what their eventual apps would look like. I was
certainly one of those people who used to design a layout, show it to the
users, get their feedback, and then start over with the C compiler, the API
reference, and a copy of Petzold. The product really started to mature at
version 3, chiefly because of the inclusion of database handling. Version 4
brought the long-awaited 32-bit support, and threw its development community
headlong into the world of COM. Version 5 brings Internet development and a
‘real’ compiler. All of these features, together with the colossal
marketing muscle of Microsoft, have turned the product into one of the most
popular development tools in the world. The product is mature enough to allow
the development of professional high-end commercial applications. According to
Microsoft more than 1 million Visual Basic 5 licences have been sold with over
3.2 millions developers using the language overall.
Before I really get going, I think that it would be in order
for me to provide a brief introduction. I’ve been in the industry since
1986, and I’m a freelance software developer specialising in Visual Basic,
SQL Server, and Windows NT. Although I’m freelance I frequently work as an
associate for The Mandelbrot Set (International). However, any opinions that I
express in this column are solely my own – unless somebody strongly
objects to something I’ve said in which case it’s probably just the
drink talking. I had a feature published in the December 1996 issue of EXE
entitled Three-Tier Architecture that covered the fundamentals of writing
remote automation servers with Visual Basic 4. Shortly after that I was invited
to join the writing team at The Mandelbrot Set on their Advanced Microsoft
Visual Basic 5 book (currently the best selling title in the range of Microsoft
Press Visual Basic books). It’s never particularly been a career decision
to get into writing on a professional basis – it just sort of happened.
Mind you, I only intended to program computers for a year or so until I decided
what sort of career I wanted…
My task with this column will be to provide an informative
monthly article that is slanted towards the Visual Basic development community.
Here’s how I intend to play it. Some will be straightforward ‘how
to’ articles that look at specific programming topics, with the usual
source code snippets and illustrations. Some will cover other aspects of
Windows technology but from the point of view of the Visual Basic developer.
For example, in future issues I’ll be looking at SQL Server administration
from a Visual Basic standpoint, Microsoft Message Queue Server, and Windows NT
user account management. My aim is to demonstrate specific Visual Basic
technologies at the same time that I cover the wider issues. I will also, where
appropriate, share comments concerning Microsoft strategy and direction,
provide coverage of new technologies as they become available and review
third-party products that I feel are directly relevant. Although the article is
aimed specifically at Visual Basic developers, I hope to present it in such a
way that the article will be generally informative to anybody who programs for
the Windows platform. I do not intend to provide a question and answer forum
– there are other publications that are more suitable for this – but
I would welcome requests via email (see details at end of article) for specific
topics to write about.
The CD
Many developers, I’m sure, just install VB and the help
files, then shove the CD back in the box and put the whole thing in a dark
corner, never to be seen again unless the hard disk crashes. This is a shame,
because there’s actually quite a lot else on the CD not installed by
default which turns out to be very useful.
The CD contains 3 root-level directories: Os, Vb and Tools.
The Os directory contains runtime support files, and the Vb directory is
largely a mirror image of what gets copied down to your hard disk if you decide
to install everything. The Tools directory, however, is not supported in the
setup program and it is up to the developer to copy over manually whatever
looks interesting. Additionally, none of the formal documentation (ie the
books) makes mention of it. From my observations, this has led to a lot of
developers simply not knowing that it’s there. Note that I’m
specifically referring to the Enterprise Edition of the product – some of
the things that I mention might not be found if you only have one of the, shall
we say, less expensive versions of the product.
A key tool (in my opinion) that doesn’t get installed is
the Help Compiler Workshop (\Tools\HCW\setup.exe). This provides a
project-based environment for the creation of standard Windows help files. Help
files are fundamental components of a Windows application and yet they are
often omitted from in-house applications (and some commercial ones!). I have
heard more than one person say that they prefer to ‘roll their own’
help files, but I suspect that this is because they have never actually got
around to using the HCW themselves. Basically if you know what an HPJ file is
(it’s a help project file) then the HCW wraps a GUI around it and helps
you to define display windows, provide context mappings, create a table of
contents file, add topic files, and so on. It also lets you test the help file
by opening it in the different supported ways (as if it were invoked by a
program, as a pop-up or just double clicked from the Windows Explorer). It
doesn’t give you an environment to edit the source RTF files directly
though – you still need an editor such as Microsoft Word for that.
As Visual Basic has matured into a corporate strength
development tool its support for SQL Server has grown too. Service pack 1 of
SQL Server 6.5 introduced hooks to cater for a remote debugging server, which
can be called from a developer’s workstation. First introduced in the
Enterprise Edition of Visual C++ 4, the TSQL debugger (\Tools\TSQL directory)
also subsequently appeared in Visual Basic 5 Enterprise Edition (along with SQL
Server itself and the SQL Server service pack 2). The client interface is
automatically installed when you choose the Typical option in the main Visual
Basic setup program, although you must additionally run
\Tools\TSQL\srvsetup\sdi_nt4.exe on the same machine as your SQL Server service
in order to install the server-side functionality. Once this is installed, you
have the facility to single step through stored procedures much as you would
any piece of Visual Basic code – unremarkable, except for the fact that
this facility wasn’t available for SQL Server beforehand. The actual
connectivity is performed via the Remote Automation Manager – expect to
see this pop into existence when you load the add-in.
As well as the SQL Server tools the ODBC Spy utility that
ships with the ODBC SDK is included in \Tools\Odbcspy. This useful tool writes
all ODBC API calls arising from your application out to a log file (or to the
screen) to help debugging. Incidentally, there is a tool within the standard
SQL Server installation called SQL Trace that does the same thing for standard
Transact SQL statements. I only mention it because I’m continually amazed
at how few people I meet actually know about it. On the subject of spy
utilities, there is also Spy++ (located in \Tools\Spyxx) which provides a very
comprehensive set of diagnostic information about processes, threads and
windows. If you’ve never used this before it can be quite instructive in
showing how Windows actually works under the hood because you can see the
low-level messages despatched by the operating system out to any application.
Finally, there is the Pspy utility (in \Tools\Pspy) that shows you which DLLs
have been loaded by any given process.
In-depth OLE
OLE Messaging is covered fairly extensively in the
\Tools\Olemsg directory. A help file documents the OLE Messaging calls, and it
provides many code samples for the most common tasks. There are also client and
server components for an overall sample application.
Finally, there is a directory called \Tools\Unsupprt, which
contains a ragbag of bits and bobs that are apparently unsupported by
Microsoft. I can’t quite see why they should take this stand, but there we
are. Among the items on offer are a calendar control, a template manager
add-in, and the Microsoft Type Library compiler. There are also some
potentially useful source code samples, notably a screen saver application, a
mechanism for using the Windows system tray (the area to the right of the
taskbar), and a means for voice communications over the Internet (using
streaming through TCP sockets). There are also a couple of projects that
demonstrate how to perform a lower level of COM communications than you would
normally do in Visual Basic (found in \Tools\Unsupprt\Shelllnk and
\Tools\Unsupprt\Ihandle). These demonstrate the manipulation of COM objects
through the IUnknown interface by directly invoking the CoCreateInstance call,
as opposed to the IDespatch interface that is automatically manipulated by the
underlying runtime routines. These would make very interesting study for
somebody who has taken the time to understand the theory behind the COM model
but has yet to see any real code that actually does anything. Lastly, there is
the code profiler (in \Tools\Unsupprt\vbcp) that has been around in earlier
versions of Visual Basic but is now implemented in the form of an add-in.
One set of components that does get installed if you choose
the ‘Enterprise components’ option in the main Visual Basic setup
routine is the Application Performance Explorer (found in \Tools\aperedis). It
is actually covered in the Visual Basic documentation (in the Guide to Building
Client/Server Applications With Visual Basic, page 42) but again I haven’t
seen this used a great deal in my travels so I feel that it’s worth a
mention here. This tool is aimed at profiling multi-tier developments by
testing different deployment configurations to determine the optimum topology
for a given architecture. The toolkit itself is delivered as four separate
executable sets: a manager, a server, a worker, and a client. The manager is
the configuration that’s installed by the Visual Basic setup program and
allows you to test everything on just one machine. Alternatively, you can
install the other three components separately (they each come with a setup
program) on different machines to bring your network performance into the
equation. The APE is itself a good example of a client/server design and as an
added bonus the entire set of source code (12 separate directories worth) is
available under \Vb\Samples\Entrpris\ape.
As a last word, it’s worth keeping an eye on
Microsoft’s Visual Basic site (http:\\www.microsoft.com\vbasic). As long
as you are a registered user you can gain access to an ‘owner’s
area’ that offers additional items such as an IE4-style CoolBar control.
Non-MSDN subscribers will also be able to download Visual Basic service packs
from this site.
