Broken refs can't be ID'd 
Author Message
 Broken refs can't be ID'd

Just noticed something that screws up a lot of my plans for checking
and adding references via code:  When a reference is broken/"MISSING"
I can't access any of its other useful properties to identify it.

I'll be coding this add-in in 2000 and exporting to 97, 2000 and 2002.
When a '97 machine receives the file, the Excel ref points to version
9.0 and therefore shows up as 'missing.'  The logical thing to do is
remove it and add the right one via code.  But I seem able only to
remove *any* broken reference -- by looping through the References
collection and testing the IsBroken property.  That is, I can't ask
for a broken ref's Name, Description, or FullPath properties (actually
they're methods, how odd) to be sure it's the one I should be removing.
Doing so gives the "Method XXX of object Reference failed" error.

Granted, since broken references aren't useful, I could have my code
just remove *any* broken refs it found, then add the Excel ref after
an On Error Resume Next.  But that seems like bad programming practice.
Is it?  Any ideas?

--

"Life is nothing if you're not obsessed." --John Waters



Fri, 11 Mar 2005 12:40:19 GMT  
 Broken refs can't be ID'd
Hi Mark

Bad programming practice or not - I've been forced to a similar solution!

Regards BosseH



Quote:

> Just noticed something that screws up a lot of my plans for checking
> and adding references via code:  When a reference is broken/"MISSING"
> I can't access any of its other useful properties to identify it.

> I'll be coding this add-in in 2000 and exporting to 97, 2000 and 2002.
> When a '97 machine receives the file, the Excel ref points to version
> 9.0 and therefore shows up as 'missing.'  The logical thing to do is
> remove it and add the right one via code.  But I seem able only to
> remove *any* broken reference -- by looping through the References
> collection and testing the IsBroken property.  That is, I can't ask
> for a broken ref's Name, Description, or FullPath properties (actually
> they're methods, how odd) to be sure it's the one I should be removing.
> Doing so gives the "Method XXX of object Reference failed" error.

> Granted, since broken references aren't useful, I could have my code
> just remove *any* broken refs it found, then add the Excel ref after
> an On Error Resume Next.  But that seems like bad programming practice.
> Is it?  Any ideas?

> --

> "Life is nothing if you're not obsessed." --John Waters



Sat, 12 Mar 2005 05:48:57 GMT  
 Broken refs can't be ID'd
Hi Mark,

Maybe I don't understand you correctly and got confused by your different questions regarding this topic, but why wait for a reference to break? Can't you create them in either the lowest version (in your case '97) or remove the references when you're distributing and set them all with code?

Hope this helps,
regards,
Astrid

So that all can benefit from the discussion, please post all follow-ups to the newsgroup.
Visit the MVP Word FAQ site at http://www.mvps.org/word/


Quote:

> Just noticed something that screws up a lot of my plans for checking
> and adding references via code:  When a reference is broken/"MISSING"
> I can't access any of its other useful properties to identify it.

> I'll be coding this add-in in 2000 and exporting to 97, 2000 and 2002.
> When a '97 machine receives the file, the Excel ref points to version
> 9.0 and therefore shows up as 'missing.'  The logical thing to do is
> remove it and add the right one via code.  But I seem able only to
> remove *any* broken reference -- by looping through the References
> collection and testing the IsBroken property.  That is, I can't ask
> for a broken ref's Name, Description, or FullPath properties (actually
> they're methods, how odd) to be sure it's the one I should be removing.
> Doing so gives the "Method XXX of object Reference failed" error.

> Granted, since broken references aren't useful, I could have my code
> just remove *any* broken refs it found, then add the Excel ref after
> an On Error Resume Next.  But that seems like bad programming practice.
> Is it?  Any ideas?

> --

> "Life is nothing if you're not obsessed." --John Waters



Sat, 12 Mar 2005 07:28:36 GMT  
 Broken refs can't be ID'd
Hi Astrid,

Mm, the different questions must look pretty odd.  I was trying to approach
it from two different angles.

Yes, I'd like to be able to edit the add-in in '97, but after October, that
won't be possible, as the '97 machine will be upgraded.  Also, it's not my
main machine now (I have access to it only in the evening), so I'd have
problems issuing a fix for a '97 user during the day.  So I'm looking for
a way to do all editing in 2000.  As you proved, if I do that, 2002 users
will be fine; but in '97 the add-in opens with that reference broken.

And while setting it via code usually does work, for some reason the code
that sets the reference causes Word to lose the focus; so although Word
launches OK, the user can't just start typing without clicking in the
window first, which is annoying.

The code I'm now using (below), which first removes ANY broken reference,
does work, but as I say, it doesn't seem right to do that.  And it also
launches Word without the focus, as above.  It seems anything that cycles
through the References collection does that.  Is there a way around that?

Thanks again for any further help.
Mark

Current code (for editing in 2000 and distributing to all versions):

Public Function NeedsExcelRef() As Boolean
Dim i As Long, ExcelFound As Boolean
' Euthanize any broken refs first
For i = ThisDocument.VBProject.References.Count To 1 Step -1
     If ThisDocument.VBProject.References(i).IsBroken = True Then
         ThisDocument.VBProject.References.Remove _
            ThisDocument.VBProject.References(i)
     End If
Next i
DoEvents
For i = ThisDocument.VBProject.References.Count To 1 Step -1
     If ThisDocument.VBProject.References(i).Name = "Excel" Then
          ExcelFound = True
          Exit For
     End If
Next i
If ExcelFound = False Then NeedsExcelRef = True
End Function

'----------------------

Sub AutoExec()
If NeedsExcelRef = True Then Call SetExcelRef
Call RestOfAutoExec
End Sub

'----------------------

Sub RestOfAutoExec
 <---Must put all of the AutoExec's code here, otherwise compiler flags
     very ordinary functions in it (Chr, Environ, etc.) as 'unknown.'
End Sub

'----------------------

Sub SetExcelRef()
On Error Resume Next
With ThisDocument.VBProject.References
  Select Case _
     Mid$(Application.Version, 1, InStr(Application.Version, ".") - 1)
   Case "8"
     .AddFromFile "C:\Program Files\Microsoft Office\Office\Excel8.OLB"
   Case "9"
     .AddFromFile "C:\Program Files\Microsoft Office\Office\Excel9.OLB"
   Case "10"
     .AddFromFile "C:\Program Files\Microsoft Office\Office10\Excel.EXE"
  End Select
End With
DoEvents
On Error GoTo 0
End Sub

Quote:

> Hi Mark,

> Maybe I don't understand you correctly and got confused by your different questions regarding this topic, but why wait for a reference to break? Can't you create them in either the lowest version (in your case '97) or remove the references when you're distributing and set them all with code?

> Hope this helps,
> regards,
> Astrid

> So that all can benefit from the discussion, please post all follow-ups to the newsgroup.
> Visit the MVP Word FAQ site at http://www.mvps.org/word/


> > Just noticed something that screws up a lot of my plans for checking
> > and adding references via code:  When a reference is broken/"MISSING"
> > I can't access any of its other useful properties to identify it.

> > I'll be coding this add-in in 2000 and exporting to 97, 2000 and 2002.
> > When a '97 machine receives the file, the Excel ref points to version
> > 9.0 and therefore shows up as 'missing.'  The logical thing to do is
> > remove it and add the right one via code.  But I seem able only to
> > remove *any* broken reference -- by looping through the References
> > collection and testing the IsBroken property.  That is, I can't ask
> > for a broken ref's Name, Description, or FullPath properties (actually
> > they're methods, how odd) to be sure it's the one I should be removing.
> > Doing so gives the "Method XXX of object Reference failed" error.

> > Granted, since broken references aren't useful, I could have my code
> > just remove *any* broken refs it found, then add the Excel ref after
> > an On Error Resume Next.  But that seems like bad programming practice.
> > Is it?  Any ideas?

> > --

> > "Life is nothing if you're not obsessed." --John Waters



Sat, 12 Mar 2005 08:42:07 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. 'Canned' data in VB program

2. Disabling Outlook 2000 Menu Items - Finding Control ID, IDs, ID's

3. VB - Crystal Report Books, refs or anything, I'm desperate

4. VB - Crystal Report Books, refs or anything, I'm desperate

5. Adding 'Continued' to Column breaks

6. Adding 'Continued' to Column Breaks

7. Adding index and links are 'broken'

8. Typo: Check for broken refs...

9. Just the BASIC's ma'am.

10. task id's of 32 bit exe's

11. runtime error object required 'id'

12. task id's of 32 bit exe's

 

 
Powered by phpBB® Forum Software