Help! My add-in won't go quietly (Word 2000)

[kevm]

My document uses code in an add-in but, when the document is closed, it keeps asking if I want to save changes in the add-in - which hasn't changed (as far as I can tell).

The add-in is added to my doc by an external program over which I no control. The Document_Open event runs 2 subs in the add-in to initialize application events and to set up a custom menu .

I read many earlier posts relating to this same issue and the 'attached template' but setting <font color=yellow>Application.AttachedTemplate.Saved = True</font color=yellow> doesn't work on an add-in.

Is there any way to stop this behavior? Should it happen to start with? <img src=/S/shrug.gif border=0 alt=shrug width=39 height=15>


TIA,
Kevin
<img src=/S/flags/NewZealand.gif border=0 alt=NewZealand width=30 height=18>

[Andrew Lockton]

Does making the add-in Read Only fix the problem?

[Kevin]

1) The template (addin) is being changed. Period.

2) I think you mean Activedocument.attachedtemplate.saved = true

3) Try putting

Thisdocument.AttachedTemplate.saved = true

in the AutoExit sub of the addin.

p.s. If the user is exiting Word via the Close Menu (X) and you cannot find the code that is making the template "dirty" (and correct it) you are hosed. That Close "event" cannot be trapped by VBA; therefore, the .saved property will not work. At least not in Word 97. I suspect it's the same for higher versions.

[jscher2000]

You can access the Saved property of any global template this way, just substitute something unique it can use to identify the file name. If you prefer to hardcode the entire template path you could dispense with the looping entirely, but this will tolerate more jostling.

<pre>Sub SetAnyTemplateToSaved()
Dim temp As Template
For Each temp In Application.Templates
If InStr(1, temp.Name, "MSFilter", vbTextCompare) Then
temp.Saved = True
Exit For
End If
Next
End Sub</pre>

[kevm]

Thanks Jeff,
That nailed it. I had to change it slightly to
If temp.name = "MyAddIn.dot" then
temp.saved=true
end if

This appears to work fine. Was there some reason you used the InStr function instead and, what was the MSFilter for in that line?

Appreciate the assist.

<img src=/S/cheers.gif border=0 alt=cheers width=30 height=16>
Kevin

<img src=/S/flags/NewZealand.gif border=0 alt=NewZealand width=30 height=18>

[jscher2000]

Without the full path, I got errors, so I worked around it by only looking for the "left" part of the file name in the full name. MSFilter is the MS template that creates "lighter" HTML from inside Word. (The code's still a nightmare, but not quite as much of one.)

[Gary Frieder]

Kevin,

<A target="_blank" HREF=http://www.wopr.com/cgi-bin/w3t/showthreaded.pl?Cat=&Board=wrd&Number=117390&page= 0&view=expanded&sb=5&o=0#Post117390>This</A> appears to work - in Word 2000. Don't recall whether these App events were available in Word 97 - probably not?

Gary

[Kevin]

Appears to work? You mean you can use the app events to trap the X close in Word 2000?

App events are available in Word 97 -- but only Document_Change and Quit (and Class init and terminate).

But the Quit app event fires AFTER the X close and so cannot be used to trap that action.

[Gary Frieder]

Kevin,

Good point - depends on what you're trying to trap.

The person in the Word forum wanted to trigger some (unspecified) code to run when (before) the app quit, and AutoExit wasn't firing in response to the user clicking on the "X".

In that respect, Application_Quit 'traps' the click on X in that the Application_Quit event does fire when the user clicks on the X.

So if what's needed is some environment/cleanup code that reliably needs to run every time Word closes, then the Application_Quit event is good enough - true it will run after the "X" is clicked, but the necessary code will run before Word quits.

If by 'trap clicking on the X' you mean trap the event and keep it from continuing i.e. prevent Word from closing when the user clicks on X, then agreed the Quit app event won't do that.

Presumably the folks who built the app events didn't contemplate needing to prevent users from quitting the app - for one thing since the default behavior in Windows is that clicking on the X closes the window.

In what circumstance would you want to keep a user from closing Word by clicking on the "X"?
Didn't someone once post some kind of API solution, maybe on the old Lounge (or am I having another one of those disassociative moments <img src=/S/spook.gif border=0 alt=spook width=15 height=15>)?

Gary

[Kevin]

Well, I don't really want to keep the user from pressing X to close Word. However, I have had to disable that Close button when I could not find where my code was causing a change to the global addin template.

The original poster here was asking about the ol' "template changed save message", so I was passing on my discovery. It is interesting that File>Exit can be trapped by writing a FileExit sub. Application_Quit would seem like the right event to trap that template changed messaged. But NO! Word's test for a changed template happens before you can trap it.

Therefore, the only way to really truely beat the "template changed save message" is to keep your code from changing the template and forget about the .saved property. (In an empiricle sense) And if you can't find the place where the code is changing the template -- look harder.