Replies

(Edited by HansV to make URL clickable – see Help 19)

The full characterization and cure for this problem was found here

It’s an undocumented side effect of a Microsoft Office hotfix (sic), which is why we’ve only seen it on a few people’s machines, it’s only those folks who’ve bothered to get fully patched that have the problem.

Joel

> I’m not positive what you’ve done, but “cover page.doc” is 1) either a template renamed from a .dot extension to a .doc extension, or 2) it’s a document.
It’s a document.

> If it’s a document, then the attached template will be the one that the “cover page.doc” document is attached to (i.e. joel.dot).
That’s what it’s supposed to do… and doesn’t after the first save (but if reset later it does stick)

>I don’t know why the attached template should change, unless you are specifically doing something to make it change.
Nope, no hooks on FileSave or anything like that.

> I’m not quite sure what you’re trying to accomplish by having .doc files as templates.
Several things
1) Macros are maintained in only one place, rather than the 200 ‘content’ templates
2) Macros are only available for documents based on the template (rather than being a global template)
3) .doc files, when placed in Documentum as their (cough) templates, make more .doc files. .dot files placed in the Templates cabinet of Documentum, make more .dot files (ick)

Actually, after posting here, I found someone else who had the same problem.
A certain security hotfix for Office 2002 (and possibly 2003) causes this problem, which is fixable with an AutoNew macro

Sub AutoNew()
dim s as string
s = ActiveDocument.AttachedTemplate.FullName
ActiveDocument.AttachedTemplate.FullName = NormalTemplate.FullName
ActiveDocument.AttachedTemplate.FullName = s
end sub

I should have mentioned that — tried that too, still fired the Document_New
It definitely happened on a machine running Word 2000 SR-1, haven’t verified yet that it still happens in SP-3, although our trainer said it happened.

Nope. First thing I checked.

I’ve been able to reproduce it by installing Word 2000 on a VMWare session, then loading my template, but it’s definitely not loaded as a global or add-in.
Can’t get the same thing to happen at all on Word XP or 2003.
Framing the statement with WordBasic.DisableAutoMacros certainly stopped the problem.

So at least I can get around this… now if Microsoft would only fix copying styles, section breaks, list templates….

My approach is to use VB (not VBA), which has a Clipboard.GetText(vbCFRTF) which will return the entire RTF as a string. The HTML might be easier to parse, especially as I want XML as my final output, based on info not obvious to Word 2003, and much less messy than WordML.
I can probably do the same thing using the SDK routines to get the clipboard, but for right now rapid prototyping, the Clipboard object is too easy not to make use of.

Nnnnn…no.

I meant, how do you find how big the run of text is that shares the same formatting? This would help for those folks trying to find the font changes in a paragraph, conversions to odd formats, etc.

In the general case, it might be best to start with the WordML or RTF and parse from there, but if I’m trying to get some info about just a paragraph or two, it can be a lot of work, checking the characteristics character by character.

Kind of ugly and expensive on macro storage, but it’s what I’m leaning toward.
The problem is that there’s four ways to load a template:
1) Open a document that’s already attached: Document_Open traps that.
2) Create a new document from the template, or from a document that’s attached: Document_New traps that.
3) Installed as a global template: AutoExec traps that
4) Attached to an open document with Tools > Templates and Add-Ins. I’m up a creek. Nothing seems to ‘happen’ when the user does this.

I’m looking at a similar problem: I’m being asked to add license management code to my template, and I’m tryinig to figure out all the places I’d have to trap.
I can trap Document_Open and Document_New, check the license, and then do something nasty like attach to Normal.dot if they’re not valid users.

However, neither of those events gets fired if the user goes to Tools > Templates and Add-Ins and just attaches to the template!
Voila, toolbars are back, full functionality has woken up!
I can’t create an application events module, because without the _Open or _New events firing, I can’t create the object that watches for events.

Any suggestions?
I’d hate to have to add license-checking code to each and every macro that would be callable from a toolbar or from Tools > Macros > Macro…

Another weird side-effect: if the document isn’t visible, Word’s range.find won’t find the empty cells at all. Much better results occur if the document is visible at least for a short period of time. Rendering it to the screen must have some side effect on the internal data structures.

It causes an unfortunate blink, but
oDoc.windows.Add
oDoc.windows(1).visible = false
does the trick.

Y’know, of all the options, doing it *AGAIN* never occured to me.
It seems to take multiple passes for some messier tables, so I’m going
while .Execute(blahblah)
DoEvents
wend

Thanks much
Joel

p.s. My first attempt at this ran on infinitely, stepping through it, it didn’t… I may not have solved it yet. Will let you folks know.

Hans,
Yeah, I was afraid of that. Typical non-orthogonality of the MS Office object model.
Most of the other objects have IDs, but styles are numbered less than zero for built-ins, and greater than zero alphabetically for user styles.
Patently absurd. I may just have to create a collection with the .namelocal as the key and the number as the value… waste of precious time and space.

Joel

(Edited by HansV to make URL clickable – see Help 19)

I should have posted that link. Been there, done that.
What I want is for the ADDIN field to have visible text too.

Reference Manager and Endnote http://www.endnote.com[/url%5D both from Thomson, both manage to have visible text as well as storing data in the ADDIN field. There aren’t any nested fields.

There must be a way to reproduce the same effect.

Any suggestions for automating detection or removal of that behavior? I’ve got lots of documents to process, and I’d like to be able to automate cleanup.
The MSWD KB wasn’t helpful.

Any suggestions for automating detection or removal of that behavior? I’ve got lots of documents to process, and I’d like to be able to automate cleanup.
The MSWD KB wasn’t helpful.

I’m already doing all of that — named list templates, styles tied to list templates, the whole nine yards.
This is happening in a brand-new doc based on a custom .dot file with things set up right, or so I thought.