For today’s blog entry, I’m going to delve into a bit of Word esoterica that, if you’re into this sort of thing, you might find fascinating, and if you’re not, well, you have been warned<g>.

If a document is changed in Word, you’d expect to get a prompt when you close the document, wouldn’t you?

Well, that’s apparently just expecting too much, my friend.

And if you were to load a document programmatically and simply iterate through it, without changing anything, you’d expect that the document wouldn’t actually change, wouldn’t you?

Well, that’s also… oh, you get the picture.

It appears to be possible in Word, without programming, to create a header that doesn’t actually exist, or rather, that exists but is completely empty.

If you then iterate through the headers of the document, retrieving the Range of each, the act of simply “retrieving” the range, not actually modifying it, will cause the header to be modified, inserting a paragraph mark where there was none before.

This can effectively shift the entire document down, since, in the original document there was no “paragraph” in the header, but now there is.

Even more interesting, this modification isn’t logged internally by Word, so if you were to close the document, you get no prompt that a change has been made, and from what I can tell, the change isn’t actually saved, although it’s very visible on-screen.

You can test this by creating a document with a null header, then, adding this VBA code and running it:

Sub Test()
   Dim sct As Section
   Dim r As Range
   Dim hdr As HeaderFooter
   
   For Each sct In Me.Sections
      For Each hdr In sct.Headers
         Set r = hdr.Range
      Next
   Next
End Sub

How do you create a document with a null header? To be perfectly honest, neither I nor a Microsoft Tech could figure that one out. Please let me know if you can.

But what I did discover was that the situation yielded something you could detect.

Essentially, the problem is this:

Each SECTION object in Word has a PAGESETUP object associated with it.

And each PAGESETUP object has an associated HEADERDISTANCE and TOPMARGIN property. It also has FOOTERDISTANCE and BOTTOMMARGIN properties, but I’ll only deal with headers here. Footers are handled in exactly the same way.

In a document’s section, if the HEADERDISTANCE is ever >= the TOPMARGIN, any changes in the size of the header have the potential for “spilling out” over the limit of the margin and pushing the content of the section body down.

I say potential, because if the header doesn’t contain anything, or if what it contains is not enough to push the bottom of the header past the TOPMARGIN, everything will stay put and all will be well.

In any case, right before you save the document, you simply need to iterate through all the headers in all the sections of the document and test if they’re empty. If they are, you force the HeaderDistance back to half of the TopMargin.

Section.PageSetup.HeaderDistance = Section.PageSetup.TopMargin / 2

Why half? It essentially doesn’t matter what it is, as long as it’s less than the TopMargin.

But what makes up an “empty” header?

Once you get the Range of the header

set Range = Header.Range

Make sure it’s not a linked header

If Range.LinkToPrevious then {it's linked so don't bother with it}

and then check the character and word counts

If Range.Characters.Count > 1 and Range.Words.Count > 0 and Range.Characters.Count > Range.Words.Count Then
   {this is NOT an empty header}
End If

If it’s empty, adjust the HeaderDistance as noted above.

Fun stuff.

Dealing with attachments in Outlook is a bit like entering an Ultimate Fighting match against a professional half-octopus, half-eel. It really doesn’t matter what style of fighting you choose, the octo-eel is guaranteed to take you down more than once in the match, and there’s really no telling whether you have a chance at winning.

An app that I’m working on deals with attachments in Outlook, more specifically, it deals with Office format attachments, so we’re talking about DOC, XLS, and PPT files (and about 2 dozen other *X and *M formats introduced in Office 07).

Anything else (like BMPs, TXT files, etc) are supposed to pass on through like yesterday’s iceberg salad.

However, astute customers noticed that, in some cases, the order of the attachments could change at times. If you had numerous attachments to your email, and you intended on them being in a particular order, that might not go over well.

Now, you might think, with such a nicely laid out object model as Outlook’s, that preserving the order of attachments in a message would be trivial. Hell, you might even thing you could simply replace one attachment with another, simply by using a replace method or somesuch.

And you’d be wrong.

There’s no replace method, unlike GroupWise. And the ATTACHMENTS.ADD method doesn’t allow you to specify an ordinal. It does allow you to specify a position, but that value is only used to indicate the character position of the attachment in an RTF format email. If the email format is plain text, or HTML, the position isn’t used at all.

Then there’s this jewel from the MSDN documentation on the add method.

To ensure consistent results, always save an item before adding or removing objects in the Attachments collection of the item.

Special.

Add to all of that the fact that Word can also be used as the email editor (albeit in approximately the same capacity as the built-in Outlook RTF editor from what I can tell), and you have a whole lot of arms to fight with on this octo-eel.

The bottom line however, turns out to be relatively simple.

1. First, you have to make a single pass through all the attachments in a message and for every one you plan on removing, you need to add the new one. In addition, for those that you don’t plan on removing, you have to extract them, then add them again anyway, in the same order as they already exist.
   This will cause the email to end up with a double set of attachments; the originals, and all the new ones, plus a second copy of any original attachments you didn’t necessarily want to mess with but have to anyway.
2. Next, make another pass through all the attachments, removing all of the original attachments, but leaving everything else. Now, the email will contain the proper list of attachments, both new and untouched originals, in the original order, at least for plain text and HTML formats.
3. For Rich Text, there’s one more trick….
4. When you add the new attachments (or re-add those attachments you intend to pass through, in step 1 above), retrieve the POSITION of the attachment first.
   If it’s 0, make sure you add the new attachment WITHOUT specifying a position argument. Specifying a 0 for the position will only mess things up.
   If it’s NOT 0, however, add the new element with a position argument of the original POSITION + 1

It sounds more complicated than it is.

If you get any part of it wrong, you’ll know pretty quick. Usually, the attachments will end up in the sent email reversed in order. Worse case, some will end up missing.

One final trick. Testing all this can be a real pain, but you can make it a little easier.

Set up Outlook with POP accounts only (don’t use Exchange for this). Then set it to NOT send email on startup:

Anything you send will end up in the outbox, where you can examine it, use it for debugging, drag it back to the inbox to attempt a resend, or delete it. And from what I can tell, whatever ends up in the outbox is what would go. There’s no additional processing done after that.

Plus, you don’t even have to use a legitimate TO address, anything that looks like an email address will work.

Believe it or not, I actually like Outlook, despite it’s, uh, quirks? It’s been my email system since about 97. I’ve never had a corrupted PST file, never lost an email (that I didn’t unintentionally delete with Shift-Del), and never gotten an email-born virus.

Now, excuse me, I have some serious knocking to attend to.