I’m sure someone, somewhere, has already done a dissertation on this, but I’ve often thought it would be interesting to look at the code of a project as if it was a living, growing thing.

You’d analyze the changes made over time to a piece of code to visualize how it becomes better, breaks, corrects, expands and ultimately dies or gets recycled refactored, as well as the people making those changes, how long it took to make the changes, the number of changes on any given day, or possibly daily trends. Does more get fixed on a monday? Do more fixes made on friday end up getting reverted and fixed again later (for obvious reasons <g>). How many changes are made on wednesdays after that big fajita lunch?

I have this mental picture of my project visually changing over time, allowing you to see things that you couldn’t see just by looking at tables and metrics. Imagine being able to look at a time-lapse video of the creation of the Grand Canyon, from, oh say 30million years back to the present, in a video of a few minutes. Or a bit like this guy’s video (taking pictures of himself everyday for 6 years or so).

But in my head the picture is a little prettier, may something like this: 

And many, probably too many, projects would be more like this:

I was investigating some strange behavior with respect to fields in Word and when, exactly, do they get “automagically” updated.

In this particular case, I had a document with a table of contents. The TOC looked completely correct, until the doc was “saved” as a PDF file using the Word 2007 PDF/XPS format plugin. In reality, it doesn’t matter whether the doc is saved as a PDF or printed, Word functions in the same way.

During the save to PDF, the TOC entries were all converted to “Error! Bookmark not defined”. In this case, that was correct. The bookmarks used to create the TOC entries had been removed, but, with the “Update fields” options set to false, I was expecting the fields in the TOC to NOT get updated.

As far as I can tell, they really shouldn’t  get updated, but they do anyway. This appears to apply to Word 2000 as well as 2007 (didn’t check all the interim versions).

So, TOC Entry fields appear to not behave by the same rules as other fields. For instance, I embedded an AUTHOR field, save the doc, then changed the Author Document property to something else, then saved as PDF. Lo and behold, the Author Field DID NOT change from it’s original value, meaning that that field type was not “auto updated” before the print/save as PDF.

Then I tried just a plain bookmark. Insert a named bookmark somewhere in the doc, then somewhere else, insert a PAGEREF field (type 37 for those Word VBA masochists) pointing to that bookmark.

The field should take on the value of the page the bookmark is defined on.

Now, delete the bookmark (not the pageref) and print.

Aha! Another “Error! Bookmark not defined”.

It’s not TOC Entries, per se, that have the problem. It’s bookmarks. It appears that even if you tell Word to NOT UPDATE fields at print, any field that references a bookmark, does get updated. And it’s not just that Word checks that the bookmark is defined or not. Word definitely updates the field referring to the bookmark. You can see this if you do the following:

1. Create 3 HEADING1 lines
2. Create a TOC, you should see 3 entries in the TOC, one for each heading 1 line, all pointing to page 1.
3. Put page breaks between each heading 1 line, to force them to separate pages.
4. Save the doc. The TOC page numbers don’t change.
5. Now save as PDF. The TOC page number DO change at this point.

Looks like a Word bug, albeit a long standing one.

And the workaround?

You have to decide between:

• Leaving the field that refer to the bookmark in the document, but deleting the bookmarks themselves, which will result in an Error.
• Deleting the bookmark AND the field that references it (which would wipe out your TOC)
• Converting all fields that reference bookmarks to text and then deleting the bookmarks (probably the best of the choices) 

There’s no easy answer to this one, unfortunately. That last option involves quite a bit of scanning through fields and bookmarks. Interestingly, Bookmarks must have a unique name, so they are pretty easy to get back to and track.

Fields, on the other hand, have no unique ID in Words object model. 

They have a “code”, but that can be the same across multiple fields.

They have an “index”, but that can change as you delete fields.

From my vantage, the lack of unique ID’s for many of the elements in the Word Object model is a significant, if not partially understandable, problem.

If you’re running Vista, you might want to check into KB938979.

It’s call the “Performance and Reliability Update for Vista”. There’s actually 2 different packs, one for 32bit and one for 64bit.

In my case, Vista Explorer was just crashing, almost constantly, when I was copying files around (I got into a house cleaning mode this morning and started shuffling files into a little better folder structures).

It’s a 10mb download, so it’s not utterly trivial, but it’s not 300mb service pack either.

I just have to wonder what actually got changed when MS rolls out patches like this. Just once, wouldn’t be interesting for MS to roll out a patch that included a DIFF report. You know, not ALL the code, per se, just what the old line was and what it was changed to, what was deleted and what was added.

Wouldn’t THAT make for some interesting reading?

Not sure if it’s working entirely yet, but it appears to at least be serving pages.

Let me know if you notice anything amiss.

Ages ago, I happened onto Bruce McKinney’s HardCore VB and the Win.TLB file that he created and I was hooked.

Ever since, I’ve been a big fan of using typelibs with VB6. They’re relatively compact, support help, work nicely with Intellisense, and, most importantly, any elements of a typelib that your project doesn’t use, don’t get compiled into you project, unlike standard VB DECLARE statements.

Furthermore, typelibs provide just about the ONLY way to access certain COM interfaces that are normally declared with attributes that make them unusable by VB.

For examples of that, check out Edanmo’s page, or the VBAccelerator stuff.

I’ve been using Matt Curland’s Excellent PowerVB Typelib editor to edit, extend, and generally hack and bash the original win.tlb (I generally don’t use unicode much explicitly, so I haven’t kept the WINU.TLB unicode variant up to date, unfortunately). Note, though that you have to buy the book to get the editor. If you do this much, the editor alone is worth it, but the book is truly the best books on low level VB6 out there.

Doing things the Right Way

However, I really wanted to get this thing back into shape, and I felt like the best way to do that was to get it BACK into IDL format, and then use the MIDL compiler on it.

You’d think that doing so would be, basically:

1. Load the TLB into OLEVIEW
2. Export the whole thing as an IDL file.
3. Edit the IDL with a text editor
4. Run MIDL on it to recompile the WIN.TLB and presto! Nice new, clean tlb file.

Sigh. Is anything ever that simple?

Problems, Problems

First, OLEVIEW exports things in completely the wrong order (I’m not exactly sure what it uses to order things other than just the defined order in the TLB). As a result, I got tons of “symbol not defined” errors when I compiled, because a call referenced a structure that was defined later in the IDL, and didn’t have forward declaration.

Shuffling LOTS of typedefs around, I resolved all that, only to end up with tons of MIDL2022 “illegal or missing value for entry attribute”, as well as MIDL2270 “duplicate UUID” errors.

The duplicate UUID errors I fully understand, even though I really don’t like it. Basically, the TLB “redefines” a number of internal COM interfaces to make them usable by VB, for instance IEnumString.

However, MIDL doesn’t allow you to redefine an interface that already exists, and that particular interface does already exist.

In that case, commonly, you just rename your new definition to, say, IVBEnumString.

And with mktyplib and Matt’s TLB editor, that’s no problem. But MIDL see’s the old IEnumString (defined in the automatically INCLUDEd OBJIDL.IDL) and the new IVBEnumString, notices that they have the same UUID (which they must) and throws that MIDL2270 Duplicate UUID error.

Bruce resolved this by actually copying the OAIDL.IDL, OBJIDL.IDL, UNKNWN.IDL and WTYPES.IDL from the Visual Studio 6 Include dir right into his TLB project, and modified them as necessary. It works because of the MIDL search rules, but I REALLY didn’t want to continue mucking with the MS IDL files. I’d much rather just redefine those that I need to redefine and be done with it. Just seems like a safer alternative.

Ok, fine, so I go back to mktyplib and move on.

Not so fast, young Skywalker!

mktyplib is an older tool (read, unsupported, not maintained, and generally considered just that much bit junk now). And sure enough, a very common element in my type lib, it doesn’t support, namely non-variant optional parameters.

I have a line of ODL (mktyplib’s prefered input file type) like:

      HRESULT _stdcall Commit([in, optional, defaultvalue(0)] STGC grfCommitFlags);

And it has no idea how to handle that OPTIONAL and I have too many of these to bother counting them all (ok, not really, there’s 64).

I really don’t want to have to make all those method parms suddenly “required” when they’re not.

The Cycle of Irritation

So, here I am, hours later, and back where I started.

I’m going to continue using the PowerVB editor to update the WIN.TLB file.

And just to recap, my version started from Bruce McKinney’s ANSI version, generally targeted at VB5, then pulls in LOTS of additional COM interfaces, ala Edanmo, VBAccelerator, and others, corrects some issues with certain calls that VB5 had no issues with but VB6 didn’t like, throws in lots of new ENUMS for parameters of functions instead of just blind LONGs where you get no Intellisense, and rounds things out with a little bit more help text for some methods (though that’s still pretty spotty).

One nasty habit of TypeLibs

One thing to be very careful of if you do start working with typelibs, is to make sure that any API function you decide to pull in and actually use will exist on the target machine.

These days, that’s not particularly hard. Win2k through Vista have changed very little as far as typical low level API’s are concerned.

At one point, my apps were running on everything from Win95 through XP, and there were definitely issues with commonly used functions existing under Win2k or XP that had no equivalent under 95 or 98. In those few cases, I just resorted to a standard VB declare and then error trapped the call. If the function wasn’t available, you’d get an error, trap it and deal with it.

However, if that same function was defined in a typelib, the app loaded will validate all implicitly linked libs and try to resolve them all at load time. If it failed for ANY function, the app won’t load at all, and all this happens before any of you VB code has a chance to do anything about it.