In the recent thread on reining in an instance of Word which is left over to the user to use and eventually close, the best solution (Çetin and Marcia with their versions of "IMPLEMENTS ApplicationEvents2" classes) is obviously an event handler.

And it works, no problem there. My question is about the location of the olb file. I know it's only to export the interface so the project manager can at least do some homework and not rely entirely on late binding, but... in their examples there was either a full path to the olb file or a CLSID.

Neither works in all cases in a distributed programming environment. I guess there's not a single version of Office that any two of the team have installed in the same location. We're pretty much all in the phase when we have one huge disk in the order of hundreds of gigabytes, and still worry about space, because every app out there wants to put something on the C: drive, specially its own self, if possible. So we've all installed the disk-eater apps, specially Office, anywhere else, mostly on some d:\program files, or even f:. So a hardcoded path won't work, unless it's
#if sys(0)="mymachine#myself"
#define hOlb="m:\y\path\to\msword.olb"
#elseif sys(0)="peter#pan"
#define hOlb="h:\is\path\to\msword.olb"
#enddefine

which can be a solution, but has "kludge" printed all over it in 72px font.

CLSID is version specific. As I stated in the other thread, the last install forces its own on each, unusable.

The solution I've found is to just take the least common denominator olb and keep a copy of it in the app directory in development, and make it pathless in the Implements clause. Questions: should I do that at runtime too? Would it break on the machines which have only newer Word installed (possibly richer interface)? Should I include it in the project, in Other Files?