[Don’t you hate it when IE throws your long post to the trash? We need a smart client for updates!]
COM AddIns for Office are a nice feature. A rather easy way to add some buttons and functionality to your documents, and even deployment isn’t too much of a hassle.
But I ran into a problem today when I had two Word documents open at once. It seems that the button was loaded for both, but was only functional for the first instance. The second instance had something that looked like a button, got clicked like a button, but all-in-all did nothing that buttons did – that is, trigger an event.
Several hours of furious debugging followed. VB6 code was translated to VB
Only after going line-by-line over the sample and copying it to my code did we get an answer:
VB controls and similar APIs tend to have a Tag property for all their controls. A convenient, loosely-typed way to store extra data about the control without having to subclass the control or design your own interface.
A great workaround for lazy programmers, up until the time it bites you back. It bites you when you have to go over someone’s code where he uses properties for data other that their intended use. It bites you when you have a “Title” field for a mailbox that is actually used to store an organizational Department. It bites you when your code doesn’t document itself – it does something other than what you expect it to do.
And that’s exactly what Office does – it uses the Tag property of the CommandBarButton to keep track of control instances between multiple open documents.
It doesn’t matter what the Tag holds – the minute you put something in it, the button works fine on as many instances of Word as you’d like.
Why does it rely on the generic, optional, misleading Tag property for this? Couldn’t they add some internal property? Some automatic mechanism? Why do I have to set a random, pointless string to an arbitrary, pointless property to get functionality to work?
Lazy workaround for Lazy programmers. Bah.