Reference is broken, but why

[Thomas Gahler]

Hi folks



I have a problem with my addin and the reference set to this file.



I develop an addin (Library.dot) that is stored in words startup-path
(subdirectory of winword.exe). In Tools / Options this path is also set in
the AutoStart-entry.

After that, I create a new template set an referenc to my Library.dot and
use this second file as an addin too. This addin will automaticlly loaded in
the AutoExec of the Library.dot (this all is made on WinXp & OfficeXP).



Now I change to my other PC (Win2000 & Office2003 SP2) and copy my two
files. One somewhere on the pc and the Library.dot to words startup-path.
Both directory are different (different drive and path) to the first
computer. Everything works fine an word automaticlly update the reference to
the new envrionment.



After this check, I sent the two files to the customer. He installed the
files the same way (one somewhere in the pc ad the other one to words
starup-path. He has the same configuration on his machine (Win2000 &
Office2003 SP2) but different file locations. In Tolls / Options the
AutoStart-entry is also set to words startup-folder.



When he starts word, I get a MsgBox (see code below), because the reference
was updated.







Public Function funcCheckReference( _

ByVal CAddinProjektName As String, _

ByVal CAddinName As String, _

ByVal CLibraryProjektName As String, _

ByVal CLibraryAddinName As String) As Boolean



Dim bReferenceExist As Boolean

Dim iReference As Integer

Dim iCounter As Integer

Dim oAddIn As Word.Template



bReferenceExist = True



'If Reference is broken, restore it

'(Code based of Dave Rado's code example)

On Error Resume Next

With Application.VBE.VBProjects(CAddinProjektName).References

For iCounter = 1 To .Count

'If there is no reference set, resumes next.

'If there is a reference set but it is broken, removes it.

If .Item(iCounter).IsBroken Then

.Remove .Item(iCounter)

'Sets the reference - if already set, resumes next

iReference = .Count

.AddFromFile Options.DefaultFilePath(wdStartupPath) & "\" &
CLibraryAddinName



'Check if a reference is added and save the right addin.

If Not (iReference = .Count) Then

For Each oAddIn In Templates

If Not InStr(0, oAddIn.Name, CAddinName, vbTextCompare) =
0 Then

bReferenceExist = False

'...some code removed here...

MsgBox "Reference updated"

Exit For

End If

Next oAddIn

End If

End If

Next iCounter

End With

On Error GoTo 0



funcCheckReference = bReferenceExist

End Function







I allways thougt, that word will automaticlly update a broken reference, if
the addin is stored in words startup-folder.

Why does it work on my computer and does it not work on my customers
computer? Does anybody has an idee?



Thanks for help







BTW: same posting is set in 'microsoft.public.word.word97vba'





--

Thomas Gahler

MVP für WordVBA

Co-Autor von »Microsoft Word-Programmierung.

Das Handbuch« (MS Press)

- Windows XP (SP2), Office XP (SP3)

 

[Jonathan West]

Hi Thomas,

The problem with references to .dot files is that (unlike references to
ActiveX DLLs) the file path to the referenced file is hard-coded.

Unfortunately, the location of the startup path in Word varies from user to
user, as by default it includes the username in the path, in the form

C:\Documents and Settings\<username>\Application
Data\Microsoft\Word\Startup\


Even if you choose to store in Word's program startup path, this also varies
between different versions of Word and depends on whether the user installed
Word into its default location of C:\Program Files\Microsoft Office\

Even if the default install path is used, the startup path varies as
follows, for Word 2000, 2002 and 2003 respectively

C:\Program Files\Microsoft Office\Office\STARTUP\
C:\Program Files\Microsoft Office\Office10\STARTUP\
C:\Program Files\Microsoft Office\Office11\STARTUP\


An alternative approach is to use the Application.Run method to call
routines in other loaded templates. Application.Run does not require a
reference, but can only call Subs and not Functions. It may be that these
limitations are manageable for you.

Another alternative is to transfer the code from Library.dot into a VB6
project and create an ActiveX DLL from it. This has certain advantages - the
reference is not path-specific. The DLL can be installed anywhere and
registered, and can then be treated by calling projects largely as if it is
a class module. The potential disadvantage is that registering ActiveX DLLs
requires admin rights on the target PC. Whether this is a problem for you,
only you can tell.

A further option is simply to include your Library.dot code in each template
that needs to make use of it.

You could also choose to install library.dot to some fixed location, and
include some code in another add-in in the startup folder that loads
Library.dot as an add-in so it is available. The disadvantage of this is
that even if you have digitally signed library code, the code will not run
for any user on Office 2003 who has set his security settings to Very High.


I've included all these options because all of them have certain drawbacks,
and I have no way of knowing which of them would meet your needs. I've used
all the methods on different occasions, so I know that they can be made to
work within their individual limitations.


--
Regards
Jonathan West - Word MVP
www.intelligentdocuments.co.uk
Please reply to the newsgroup
Keep your VBA code safe, sign the ClassicVB petition www.classicvb.org

 

[Thomas Gahler]

Hallo Jonathan

Thanks for your informations.

I know the problem about the hard-coded path.
I know the differents about words startup path.
And I can't use the alternative approches that you tells me :-(

At the time I can't find the KB-artikle on microsoft.com, but Dave Rado
wrote me a few years ago «...In Word 2000, you don't have the problem, Word
2000 automatically fixes references to addins in Word's startup
directory...»

And this works allready on different installations, but it does not work in
one environment.

I develop on my PC
- Windows XP / Office 2002
- F:\Programme\Microsoft Office\Office10\Startup

In my office (the reference will be updated)
- Windows XP / Office 2002
- C:\Programme\Microsoft Office\Office10\Startup (diffent drive)

I tested at home (the reference will be updated)
- Windows 2000 / Office 2003
- C:\program files\Microsoft Office\Office11\Startup (differnt drive and
path)

My customer has (the reference will *not* be updated)
- Windows 2000 / Office 2003
- C:\Program Files\Microsoft Office\Office 11\Startup (differnt drive and
path)


I allways thougt, that this will work fine in every environment. But it
doesn't.

So I ask, why that and does everybody know about that behavior?


--
Thomas Gahler
MVP für WordVBA
Co-Autor von »Microsoft Word-Programmierung.
Das Handbuch« (MS Press)


- Windows XP (SP2), Office XP (SP3