Working Hard To Keep Up

This article appeared in the December 1999 issue of EXE. The main point of the article was a general comment on how much broader a knowledge is required by a Visual Basic developer than was required a couple of versions ago.

---

It seems remarkable to me how quickly the PC landscape has altered over the last decade. Ten years ago there were no Visual Basic developers, and the now primitive Windows 3.0 was considered by many, with the notable exception the Apple Mac community, to be leading-edge technology. When Visual Basic did arrive around 1991/2 it revolutionised the development of Windows applications because it offered an alternative to writing everything in C. The biggest problem that held back even wider adoption from the outset was that the first couple of versions were badly lacking in the core area of database support. Looking back at these early versions I’m struck by how limited the feature set seems to be.

The functionality available within Visual Basic, or any decent Windows application development tool, is of course a reflection of what’s available within Windows itself. Each successive version of Windows has offered more functionality, but has therefore also required the Windows development community to adopt a higher base level of knowledge in order to write anything halfway decent. By the time you read this Microsoft might well have released Windows 2000 to manufacturing and the pace will have been stepped up again. I’m reminded of Douglas Adams’ excellent Hitchhikers Guide to the Galaxy five-part trilogy in which he expounds a theory that if ever the true workings of the universe are ever understood then it will automatically mutate into something more complex (there was a second theory that this has already happened). I sometimes feel this same theory applies to Windows.

The enterprise edition of Visual Basic is now shipped with a complete copy of Microsoft BackOffice, and there is direct support for Transaction Server and Message Queue Server. Gone are the days when somebody could just specialise in Visual Basic, you now need to work much harder just to keep up. To work on a software development project properly you also need to be familiar with installation issues, help file creation, Windows interface guidelines (including the principles of feedback, forgiveness, and consistency), and so on. And of course the second half of the nineties saw the rapid rise of the Internet. I would be surprised if there are many developers out there who do not at least use it regularly, but how many of you have studied the development issues surrounding it? The Internet is here to stay (at least until it, too, mutates), and the world of e-commerce will be the next boom area. Tony Blair has urged the UK not to get left out in this arena, though I must say I don’t think this will happen in the long run. Most companies have now woken up to the potential that the Internet has to offer, and it’s likely that companies will generally make a large investment in e-commerce next year once the millennium–induced inertia starts to wear off. This is where your next area of training should be. I’ve already devoted a couple of columns this year to WebClasses, and have a few more Internet related articles in mind for next year. The reason I mention all this is that I’m concerned that some developers still seem to regard it as being someway off yet and therefore not worth worrying about too much. Any such complacency is especially dangerous if you’re likely to be job hunting or, even worse, are self–employed because you’ll find yourself being unsuitable for an increasing number of vacancies as the year progresses.

The next version of Visual Studio, and therefore Visual Basic, is some way off yet so there is nothing to be gained by speculating what specific features will be present It is worth mentioning, however, that Microsoft have publicly stated that the next version – codenamed Rainier – is concerned with closer integration of Windows 2000, Com+, and SQL Server 7. There is very little development taking place right now that is specifically targeted at Windows 2000 (apart from the commercial software producers of course), but if you want to be ready for this new platform then now is the time to start reading up on it.

CallByName

One of the features that was introduced into the latest release of Visual Basic is the CallByName function. This function was fairly high on some people’s wish list, especially to those who came from a Clipper background (a popular dBase compiler before Windows really took off) where they had already been used to a similar feature. The purpose of this function is to let you derive or supply at run time the name of an Automation object method or property, as opposed to hard-coding a specific method or property as is done most of the time. This isn’t something that you’ll need to do for most projects but occasionally it can come in useful, for example when you are interactively testing the functionality of a new component through a test harness application. It can also be very useful if you are creating controls at runtime, or if you need to write pool managers for pre-created objects.

The syntax is defined as:

Reply = CallByName(Object As Object, ProcedureName As String, CallType As vbCallType, Optional Arguments() As Variant)

The first parameter simply relates to the object upon which you want to act, while ProcedureName is a string expression containing the name of the method or property that you are calling. The CallType parameter denotes the kind of procedure that you are calling and will be expecting one of the predefined constant values which can be vbGet, vbLet, vbSet, or vbMethod. The final parameter is a variant array which should contain the correct number of parameters that would be expected for the actual procedure. For example, you could alter the caption property of a command button in two ways. The normal way would be

Command1.Caption = "Press me"

Or you could perform the same thing by using CallByName, as below:

Dim Reply As Variant
Reply = CallByName(Command1, "Caption", VbLet, "Press me")

The value in the Reply variable depends upon what you have called. In the case of a vbLet as shown above there won’t be a return value and so Reply will be empty. However if you were to invoke the vbGet form instead, such as

Reply = CallByName(Command1, "Caption", VbGet)

then you will find Reply populated with the string that was returned from the Caption property, in this subsequent case “Press me”.

Because the invocation of CallByName doesn’t support the cosy type checking that we normally find with early binding against type libraries it’s very easy to provide an incorrect property name or an incorrect list of parameters; therefore it’s very important to provide an error handler. It is safer to declare the reply variable as a variant data type so that any kind of reply can be accepted without causing a type mismatch, but care should be exercised in the provision of parameters.

CallByName isn’t something that you’re going to use every day, but it can be very useful at times. However, apart from the fact that it’s so much easier to make a mistake than an early bound call you also need to be aware that there is a performance hit. Late bound calls are a bit slower because of the extra work that is required to navigate the data structures of the underlying COM objects, but a CallByName call is slightly slower still. For a single invocation a user isn’t really likely to notice but beware if you’re intending to call an iterative loop because the delay will be magnified.

More Sheridan products…

I’ve recently taken a look at the new CodeAssist product from Sheridan. This utility is concerned with generating database access code from a source template. The measurement of how “good” a piece of code is largely depends upon the viewpoint of the individual so I won’t offer too much opinion other than to observe that the code that was produced when I tried it seemed fine. Because the overall concept is based around templates you can easily change the layout in whatever way suits you. The template language also includes a good selection of macros that get resolved at code generation time. For example if you are encapsulating a table into a Visual Basic class module then three lines of macro code will generate an enumeration of each field into pairs of Property Get/Let procedures.

I know of several software development companies that have produced their own in-house version of a tool such as this, and to be honest I very nearly did the same thing myself a couple of years back when I was producing a set of middle-tier components for a large database. Because of the flexibility of being able to modify the template code – or even create new templates entirely – I would imagine that this tool could be of use to a lot of development companies, small and large.

To use the tool it is first necessary to connect to a database, and then to choose a table or a data view. Once the required data elements have been chosen the resulting definition is stored in a Data Object, which then forms the basis for the subsequent code generation operation. This two-stage approach can be quite useful if you are looking at concurrently creating code for two different languages, for example Visual Basic and ASP.

The supplied templates cover the main data sources such as ADO, RDO, DAO, and VBSQL. There is also support for writing Internet-based components (ISAPI and ASP), and even Microsoft Transaction Server is supported. There is also some support for Delphi and C++. As with other Sheridan products there is no printed documentation, but as usual the quality of the on-line help makes up for this. There is also a good on-line tutorial to get you up and running. The product retails at £215 plus VAT, and is available from the main UK software resellers. A demo version is downloadable from http://www.contemporary.co.uk.

Last year I reviewed the ActiveToolBars product, also by Sheridan. I’d just like to follow that up by reporting that a new version, ActiveToolBars Plus, is now available which also provides emulation for Office 2000 menus. This includes the optional auto-hiding of infrequently used menu items, sliding/unfolding menus, and end-user customisation. Furthermore there is a new feature called ActiveTabs which is an alternative to the tab controls already provided by Visual Basic. From what I could see it offers everything that the Microsoft Tabbed Dialog Control does, but it also contains a few visual features that tie in with some of the latest interface doodads to be found in Windows 2000/Office 2000. Specifically the Microsoft control only offers two display styles, whereas the Sheridan tool offers four styles. It is also possible to place controls within a common area so that they are visible regardless of which tab page is actually being displayed. The review copy that I was sent contained version 2.00, although version 2.01 is available at the time of writing from their website at http://www.shersoft.com. The full product costs £149 plus VAT, whereas the upgrade cost is £59 plus VAT. My thanks to Contemporary plc for the review copies.

And so all that remains is for me to wish you all a happy Christmas and a bug–free rollover. I’d also like to take this opportunity to remind you that I’d welcome requests for specific topics to write about. Some of you email me with Visual Basic questions which I’m happy to answer when I can, but I apologise for the odd occasion when I just haven’t had the time – the Y2K problem has kept me very busy this year too. See you on the other side!