C
Chuck
We're trying to troubleshoot some strange behaviour caused by third party add
ins and have a general question about good coding practice -- whether tis
best to use built-in Word functions or to acheive the same functionality by
binding objects to command bar controls and then executing the objects.
We are switching from one document management system (DMS) to another. We
have a couple of our own add ins with customised toolbars that work just fine
with the old DMS but the new DMS doesn't save documents properly when a
specific control is on one of our add in's toolbars.
Specifically, we have a "Save As" button on one of our toolbars, which was
created by dragging the File Save As command onto the toolbar (Tools >
Customize > etc). This poses no problem with the old DMS. However if that
control is on the toolbar the new DMS displays an error when saving documents
(along the lines that no active document is available to save -- in order to
save a document the DMS closes it then opens it, don't know why, that's just
the way they do things).
We've tried to figure out what could be choking on that control and have
looked in the Word add in that the DMS provides. There are two Save related
subs in a module called "AutoMacros" in that add in (see code below). They
both create objects then execute those objects in order to save and save as
(snips follow):
Sub FileSaveBinding()
[snip]
Set objSave = Word.CommandBars("File").FindControl(ID:=3)
objSave.Execute
[snip]
End sub
Sub FileSaveAsBinding()
[snip]
Set objSaveAs = Word.CommandBars("File").FindControl(ID:=748)
objSaveAs.Execute
[snip]
End sub
If we rename those macros, then the save function works fine with the Save
As control on our customised toolbar. If those macros are not renamed, then
the DMS chokes on the control.
Question is: why would the DMS-supplied code be necessary? Why create and
then execute objects that refer to standard command bar controls like File
Save and File Save As, when those functions are available directly (eg
ActiveDocument.Save and Activedocument.SaveAs)? It seems to us an
unnecessary reinvention of the wheel but we were wondering if there is a good
rational (generally speaking) for times when it's preferable to set objects
to controls rather than using built in commands?
Please let me know if the above is unclear. Below is the code from the new
DMS add in that seems to be the problem. Thanks in advance...
Sub FileSaveBinding()
On Error Resume Next
Dim objSave As CommandBarButton
If Word.Documents.Count = 0 Then
Exit Sub
End If
Set objSave = Word.CommandBars("File").FindControl(ID:=3)
objSave.Execute
End Sub
Sub FileSaveAsBinding()
On Error Resume Next
Dim objSaveAs As CommandBarButton
If Word.Documents.Count = 0 Then
Exit Sub
End If
Set objSaveAs = Word.CommandBars("File").FindControl(ID:=748)
objSaveAs.Execute
End Sub
ins and have a general question about good coding practice -- whether tis
best to use built-in Word functions or to acheive the same functionality by
binding objects to command bar controls and then executing the objects.
We are switching from one document management system (DMS) to another. We
have a couple of our own add ins with customised toolbars that work just fine
with the old DMS but the new DMS doesn't save documents properly when a
specific control is on one of our add in's toolbars.
Specifically, we have a "Save As" button on one of our toolbars, which was
created by dragging the File Save As command onto the toolbar (Tools >
Customize > etc). This poses no problem with the old DMS. However if that
control is on the toolbar the new DMS displays an error when saving documents
(along the lines that no active document is available to save -- in order to
save a document the DMS closes it then opens it, don't know why, that's just
the way they do things).
We've tried to figure out what could be choking on that control and have
looked in the Word add in that the DMS provides. There are two Save related
subs in a module called "AutoMacros" in that add in (see code below). They
both create objects then execute those objects in order to save and save as
(snips follow):
Sub FileSaveBinding()
[snip]
Set objSave = Word.CommandBars("File").FindControl(ID:=3)
objSave.Execute
[snip]
End sub
Sub FileSaveAsBinding()
[snip]
Set objSaveAs = Word.CommandBars("File").FindControl(ID:=748)
objSaveAs.Execute
[snip]
End sub
If we rename those macros, then the save function works fine with the Save
As control on our customised toolbar. If those macros are not renamed, then
the DMS chokes on the control.
Question is: why would the DMS-supplied code be necessary? Why create and
then execute objects that refer to standard command bar controls like File
Save and File Save As, when those functions are available directly (eg
ActiveDocument.Save and Activedocument.SaveAs)? It seems to us an
unnecessary reinvention of the wheel but we were wondering if there is a good
rational (generally speaking) for times when it's preferable to set objects
to controls rather than using built in commands?
Please let me know if the above is unclear. Below is the code from the new
DMS add in that seems to be the problem. Thanks in advance...
Sub FileSaveBinding()
On Error Resume Next
Dim objSave As CommandBarButton
If Word.Documents.Count = 0 Then
Exit Sub
End If
Set objSave = Word.CommandBars("File").FindControl(ID:=3)
objSave.Execute
End Sub
Sub FileSaveAsBinding()
On Error Resume Next
Dim objSaveAs As CommandBarButton
If Word.Documents.Count = 0 Then
Exit Sub
End If
Set objSaveAs = Word.CommandBars("File").FindControl(ID:=748)
objSaveAs.Execute
End Sub