Video Screencast Help
Search Video Help Close Back
to help
New in the Rewards Catalog: Vouchers for "Symantec Technical Specialist" and "Symantec Certified Specialist" exams.

Word and powerpoint Add-in

Updated: 21 May 2010 | 10 comments
nac's picture
0 0 Votes
Login to vote
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

Comments

EdT's picture
23
Oct
2009
0 Votes 0
Login to vote

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.

VBScab's picture
23
Oct
2009
0 Votes 0
Login to vote

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.

nac's picture
26
Oct
2009
0 Votes 0
Login to vote

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

VBScab's picture
27
Oct
2009
0 Votes 0
Login to vote

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.

nac's picture
28
Oct
2009
0 Votes 0
Login to vote

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

 

EdT's picture
29
Oct
2009
0 Votes 0
Login to vote

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.

VBScab's picture
29
Oct
2009
0 Votes 0
Login to vote

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.

philbenson's picture
29
Oct
2009
0 Votes 0
Login to vote

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

VBScab's picture
29
Oct
2009
0 Votes 0
Login to vote

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.

EdT's picture
29
Oct
2009
0 Votes 0
Login to vote

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.