Word and powerpoint Add-in
Updated: 21 May 2010 | 10 comments
This issue has been solved. See solution.
Hi
When I install one application it adds add-in in powerpoint and word with the help of normal.dot file. but when I uninstall application I can still see add-ins there. Any idea on how to remove these add-ins or editing normal.dot file(not recommended)?
There are no registry entries for these addins.
Thanks
discussion Filed Under:
Comments
How are you handling Normal.dot?
Are you replacing Normal.dot when you install your application? Are you backing up the old version of Normal.dot?
I would suggest that restoring the old version of Normal.dot would be the best strategy, but this file is locked whenever Word is running, so replacing it with the previous version would require use of the PendingFileRenameOperations registry key and a reboot. Alternatively, you could add a command to the runonce registry key, to copy the old normal.dot over the existing one, as the machine is started, and before Word gets loaded.
If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.
Office add-ins can be handled
Office add-ins can be handled easily enough using the target application's Automation model. Record a macro while you add/remove the add-in and you end up with VBA code (Alt+F11 gets you into the VBA editor). Converting to VBS is simple enough. Generally speaking all you need to do is remove the data typing from the variable declarations (e.g. 'Dim blah As String' becomes 'Dim blah')
Don't know why 'x' happened? Want to know why 'y' happened? Use ProcMon and it will tell you.
Think about using http://www.google.com before posting.
Hi VBScab, Thanks
Hi VBScab,
Thanks for your assistance, I recorded a macro and it works fine when I run it from vba editor. But all I got is this code, and I am not getting how to use this macro separately on different machines.
Sub Macro1()
'
' Macro1 Macro
' remove bull
'
Application.OrganizerDelete Source:= _
"C:\USERS\USERINF\MSOFFICE\TEMPLATE\NORMAL.DOT", Name:="Bullfighter", _
Object:=wdOrganizerObjectCommandBars
End Sub
Time to learn some VBA, I'd say
The 'Application' keyword can be replaced with the name of the Word Application object which you would create in the script. You also need to use the Object Browser in the VBA Editor (press F2) to find out what value the variable 'wdOrganizerObjectCommandBars' has. Look at the Word object in the Object Browser, select 'Globals' in the 'Classes' list, then scroll the right-hand pane down to 'wdOrganizerObjectCommandBars'. Click that once and its value will be shown just above the 'Immediate' window. Most stand-alone variables like this have the value '0' (zero) but check.
So, assuming it's zero, you might end up with (STILL no <code> tag in this wretched forum...):
<code>
Option Explicit
Dim objWord
Dim strTemplatePath
Dim strTemplateName
Dim strAddInName
Const wdOrganizerObjectCommandBars = 0
strTemplatePath = "C:\USERS\USERINF\MSOFFICE\TEMPLATE"
strTemplateName = "NORMAL.DOT"
strAddInName = "Bullfighter"
'// First things first - can we create a Word object? No sense continuing if not...
On Error Resume Next
Set objWord = CreateObject("Word.Application")
On Error Goto 0
If Not IsObject(objWord) Then
WScript.Quit(False)
End If
Call RemoveAddIn(strTemplatePath, strTemplateName, strAddInName)
Set objWord = Nothing
Sub RemoveAddIn(ByVal strTemplateFolder, ByVal strTemplateTarget, ByVal strAddIn)
Dim strTemplate
'// The purpose of having separate path and name for the template is
'// to allow you to add error-trapping code, e.g. to test for the
'// existence of the path and the template
'//Once we're happy that the path and template exist, build an easier-to-read variable
strTemplate = strTemplateFolder & "\" & strTemplateTarget
objWord.OrganizerDelete Source:=strTemplate, Name:=strAddInName, Object:=wdOrganizerObjectCommandBars
'// Worth adding a check - somehow - to check whether it got deleted.
'// Perhaps there's an means to enumerate add-ins?
End Sub
</code>Please note that this is stream-of-consciousness code and completely untested.
Lastly, always, ALWAYS make a back-up of NORMAL.DOT and, if possible, avoid adding add-ins (and other junk like styles) to that template in the first place. If (sorry, when) it breaks, Word is screwed.
Don't know why 'x' happened? Want to know why 'y' happened? Use ProcMon and it will tell you.
Think about using http://www.google.com before posting.
working one
Option Explicit
Dim objWord
Dim strTemplatePath
Dim strTemplateName
Dim strAddInName
Dim oshell,SD
Set oshell=CreateObject("Wscript.shell")
SD=oshell.ExpandEnvironmentStrings("%SYSTEMDRIVE%")
Const wdOrganizerObjectCommandBars = 2
'Set objwdobject = CreateObject("Word.WdOrganizerObjectCommandBars")
strTemplatePath = SD & "\" & "Users\USERINF\MSOFFICE\TEMPLATE"
strTemplateName = "NORMAL.DOT"
strAddInName = "Bullfighter"
On Error Resume Next
Set objWord = CreateObject("Word.Application")
On Error Goto 0
If Not IsObject(objWord) Then
WScript.Quit(False)
End If
objWord.Visible=True
Call RemoveAddIn(strTemplatePath, strTemplateName, strAddInName)
Set objWord = Nothing
Sub RemoveAddIn(ByVal strTemplateFolder, ByVal strTemplateTarget, ByVal strAddIn)
Dim strTemplate
strTemplate = strTemplateFolder & "\" & strTemplateTarget
objWord.documents.open(strTemplate)
objWord.OrganizerDelete strTemplate,strAddInName,wdOrganizerObjectCommandBars
objWord.quit true
End Sub
Cool
Thanks for sharing your code with us
If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.
Where's the error-trapping?
Add some traps to RemoveAddIn so that you can be sure the path and file exist.
The Golden Rule in programming is: Assume Nothing.
Also, it's much neater to use the With keyword when you have to use an object over and over. It saves the interpreter (let's call it) from having to continuously fetch the object pointer:
<code>
With objWord
.documents.open(strTemplate)
.OrganizerDelete strTemplate,strAddInName,wdOrganizerObjectCommandBars
.Quit true
End With
</code>
Don't know why 'x' happened? Want to know why 'y' happened? Use ProcMon and it will tell you.
Think about using http://www.google.com before posting.
The Golden Rule is
Always assume the worst... it's called defensive programming, and as you state assume nothing ;-)
I always used to get called when I used to code, that I used too much try / catch error checking but it saved me lots of grief in the long run...
Just my tuppence
Phil
Ditto
I, too, have encountered that insane attitude. If forced to cave, my gambit has always been to have the client sign it off with my caveat(s) attached. That way, I'm in the clear.
Don't know why 'x' happened? Want to know why 'y' happened? Use ProcMon and it will tell you.
Think about using http://www.google.com before posting.
Murphys Law
Any program you have coded will always error out in a scenario that your error handling has not allowed for. The more error handling you include from day 1, the less chance of unexplained crashes.
If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.
Would you like to reply?
Login or Register to post your comment.