I remember a time when I was younger that if the statement When I was your age. came out of the mouth of an adult it would send a chill down my spine. The mind would race for reasons to leave the room as quickly as possible.
Imagine my shock when I heard those very same words come out of my mouth. (Ive been working in the PC world since the days of CP/M, the Apple IIe and TRS-80s with 8-inch floppy drives). It all happened one day during a team meeting. A discussion was heating up between one of the UNIX programmers (about age 30) and one of the younger Microsoft programmers (about age 24).
The UNIX guy was explaining how the older code worked (which was written in a procedural style) when the Microsoft guy then made a comment about the code leading to a defensive territorial based response by another team member. The debate on programming design methodology was moving out of control. In an effort to get control and bring order to the meeting, it happened. Those words just came out. Much to everyones dismay, including my own.
WHEN I WAS YOUR AGE we used to call object modules written in assembler code. So lets not pick on the old code, it did its job. Everyone now has to understand what it does in order to port it.
Need I say more. There was silence. Everyones mind I knew was racing for a reason to leave the room. You could see the fear in their faces that the old guy might get started again. At any rate, I was then able to redirect the discussion of the meeting into a more productive discourse of the business at hand. Which in this case was to understand the old code and write a Windows based client program that would be accessing the data on a UNIX server.
That was when I realized DREAMS DO COME TRUE. Think about it, here we are today working with huge object models. They have all the tools we could ever need to develop applications in Visual Basic. Yes we all carry our little code toolboxes (mine consists of three CDRs in size).
But today that toolbox is a collection of programs written in VB. They are my example programs, which demonstrate how I used another programs object model to solve a specific problem. One of my favorite example programs in the toolbox uses the Excel Object Model to grab some sales information and pop it into a 3D histogram and then rotate on the monitor. Its the stuff we dreamed about years ago. But its not the same as the old days. You see we dont need to carry little object modules written in assembler code to move the cursor around on the screen anymore.
Think about it. Its wonderful to be an Applications Developer in corporate America today. We dont sweat the tools anymore. We actually get to concentrate on the application. One of the first things I do when I meet with the client is to find out what their standard desktop setup consists of. Generally they have Microsoft Windows and Office 97 installed on every machine. These two products and their object models have everything I could possibly need for developing a robust enterprise application. Plus Im not even including that smorgasbord of goodies that comes with Visual Studio 6 for developing applications.
Years ago we had to develop our own library of tools just to access a database or develop a data entry screen. But I can feel secure that if there is a VBA enabled application that the client owns on their desktop there is more than likely an Object Model loaded with all the tools I need. Plus the client has already licensed it.
Has anyone really stopped to look at what is out there on the desktop today?. Lets run the numbers. In Microsoft Office 97 alone there are more than ten application specific object models. The eight larger ones total some 644 Objects with over 12,304 Properties and Methods for us to use. Descriptions of some of them are as follows.
The first one is DAO 3.5 (aka: the Jet Database Engine), every VB programmer knows this one. We all learned database access in VB with it. It has ONLY 37 Objects and 409 Properties and Methods in it. Its a baby in size compared to the rest of Office. (We are only talking about MS Office 97 here. Yes the cooler database tools like RDO 2.0 and ADO 2.1 are in VB 6).
Everybodys favorite is the Access 8.0 Object Model. It has 51 Objects and 2128 Properties and Methods to its name and has become a popular backend for VB programmers. Some programmers even prefer to prototype their application in Access, later scaling the database up to SQL Server 6.5 (and now version 7.0 of SQL Server has wizards that make this task even easier).
Even larger in MS Office 97 suite is the PowerPoint 8.0 Object Model. It has 110 Objects and 1519 Properties and Methods. Ive known of only two people who have seriously developed applications with this model. The applications were demo programs for marketing purposes and were placed on the sales force fleet of laptop computers. I have to say that Ive just recently stopped to take a second look at this one. Because Microsoft has recently introduced MS Agent 3.0 that could be combined with PowerPoint and some web tools. With that set of tools we may be able create elaborate training and help systems for use over a companys intranet.
Its time to crunch some numbers with the Excel 8.0 Object Model. This is the second largest of the MS Office 97 Object Models. At first glance it would appear to be the largest with 184 Objects and a whopping 9175 Properties and Methods. But the catch here is that 52 of these objects were for compatibility with older versions of Excel and are on their way out possibly as soon as Office 2000. Taking this into account Excel has 132 Objects with 2959 Properties and Methods.
Access and Excel are the most known and written about products in MS Office 97. There is a wealth of information and books on how to program with VBA or using the Object Models. Many companies have released add on tools and utilities for them and there has been many an in-house application that is based on these two object models.
By far the largest is the Word 8.0 Object Model. It is the least documented or written about object model. For many it is the most mysterious with great reason. Until Office 97, Microsoft hadnt put the same effort into developing it. For what ever their reason I assume it involved economics and what was selling the most. After all it was JUST a word processor. Besides every programmer in school creates a basic editor. No big deal right?
But this is now. Microsoft had to update Office to have VBA 5.0 and the Word Object Model was updated. Boy what an update too. Word 8.0 is HUGE. It has 188 Objects and 3137 Properties and Methods. You could spend years getting to know it better. (As a side bar: Authors Julianne Sharer and Arthur Einhorn are writing the first book on Programming the Word Object Model which is due for release in June 2000 from OReilly & Associates.)
For me personally, when I see it is on a machine I use it instead of the Printer Object for all my printing needs. How can you go wrong? In its simplest form you can blast a SQL query record set from a 20,000 record database into a MS Word formatted table in a matter of seven (yes; 7) seconds into an eleven-page report faster than the printer can spit it out. Oh yea I forgot to mention that Word is invisible when it does this, so no one has to know you are using word to print that really cool report. (This is what we call a teaser for another article to come).
I guess now the real question is not if dreams do come true. One looks at all those tools in MS Office 97 and then in Visual Basic 6 and I know for sure that my dreams for the future of applications programming did come true. They are here and now.
The question now is whether it was a good dream or a nightmare? I was never good with names. I have a problem like most parents under stress, and that is keeping my childrens names straight. My dilemma now is how do I keep track of all the tools in the toolbox? What they all do? What to use? How and where to use it?
Remember. Be careful what you ask for. You may get it.
