Results 1 to 8 of 8
  1. #1
    5 Star Lounger
    Join Date
    Mar 2001
    Location
    New York, NY
    Posts
    922
    Thanks
    2
    Thanked 12 Times in 11 Posts

    CommandBar.Control (Word XP)

    I'm using the following code to "press" the SaveAs item from the File menu. It functions as expected on three or four PCs. On the fourth PC, an error says "Macro cannot be found or is disabled be
    cause of macro security settings." This message appears at the .Execute line. On the other PCs, security is set to Hihg; on this PC, I've tried it at High, Medium & Low... all with the same results with this error.

    OnError Resume Next is necessary; otherwise an error is raised stating that the button cannot be found, but the macro nevertheless works correctly. This is a known bug, so I understand.

    The code:

    Sub SaveNewDocument()
    On Error Resume Next

    Dim objMenuBar As Office.CommandBar
    ' the menu
    Dim objSaveAsButton As Office.CommandBarButton
    ' the save as button
    ' Get the menu.
    Set objMenuBar = Application.CommandBars("File")
    ' Get the save as button.
    Set objSaveAsButton = objMenuBar.FindControl(ID:=748)

    ' Press the save as button.
    objSaveAsButton.Execute

    ActiveDocument.Saved = True

    End Sub
    Any idea why this is troublesome on only one PC. All are Office XP, SR-1.

    Thanks.
    Richard Barrett

  2. #2
    Super Moderator
    Join Date
    Dec 2000
    Location
    New York, NY
    Posts
    2,970
    Thanks
    3
    Thanked 29 Times in 27 Posts

    Re: CommandBar.Control (Word XP)

    Richard,

    Where are you running this macro from?
    Usually that message occurs when you've associated a macro with a menu item (using customize), and then have changed the 'path' associated with that macro in some way.
    Would anything like this be relevant in your situation?

    Gary

  3. #3
    5 Star Lounger
    Join Date
    Mar 2001
    Location
    New York, NY
    Posts
    922
    Thanks
    2
    Thanked 12 Times in 11 Posts

    Re: CommandBar.Control (Word XP)

    It's run from another macro to "force" a save of a new document. We clock the amount of time spent on documents for each client, so we require users to save at the beginning of each macro. So, for example, the first thing the letter macro does is run this procedure.

    The macro itself is running fine... it's just that the .Execute line of code raises this error. The macro from which this macro was called then continues as usual. If I step through the code, the message appears on the .Execute line, and the SaveAs dialog does not display. Again, this is on only one of four PC's, all of which seemingly have the same set up.

  4. #4
    Super Moderator jscher2000's Avatar
    Join Date
    Feb 2001
    Location
    Silicon Valley, USA
    Posts
    23,112
    Thanks
    5
    Thanked 93 Times in 89 Posts

    Re: CommandBar.Control (Word XP)

    If you use the Word object model does it circumvent the error?
    <UL><LI>ActiveDocument.SaveAs "c:test.doc"

    <LI>Dialogs(wdDialogFileSaveAs).Show[/list]If so, I would suspect something weird in the menu or toolbar customization on that machine. Although these kinds of methods are not available across Office, and therefore you might be losing some consistency, they work pretty well for Word, and allow you to detect, for example, whether the user actually is saving the document:

    If Dialogs(wdDialogFileSaveAs).Show = -1 Then
    MsgBox "User Saved!"
    End If

    Hope this helps.

  5. #5
    5 Star Lounger
    Join Date
    Mar 2001
    Location
    New York, NY
    Posts
    922
    Thanks
    2
    Thanked 12 Times in 11 Posts

    Re: CommandBar.Control (Word XP)

    No, we don't want to use the "Word object model", because that will cause the native Word save dialog to appear. We are using a document management system which "grabs" the various toolbar icons and menu items. So the only way to "force" a save in iManage is to programatically "press" the icon or choose the menu item. Doing this will display the iManage document profile screen. And, when iManage is not loaded (i.e. the command bar items have not been comandeered by the DMS), the normal Word save feature runs.

  6. #6
    Super Moderator jscher2000's Avatar
    Join Date
    Feb 2001
    Location
    Silicon Valley, USA
    Posts
    23,112
    Thanks
    5
    Thanked 93 Times in 89 Posts

    Re: CommandBar.Control (Word XP)

    Maybe you should get a second opinion from a different consultant! Most document management systems (we use WORLDOX and I have used DOCS Open) have API calls and custom procedures to Save. You should not have to fake a button press to integrate with a DMS. Maybe what's happening is that pressing the button is running a procedure or function in a global template, and you just need to figure out the name of the procedure or function and call/run it directly. What happens if you put:

    Application.Run "FileSaveAs"

    in a macro - does it trigger the iManage integration? If not, I think I can't help you.

  7. #7
    5 Star Lounger
    Join Date
    Mar 2001
    Location
    New York, NY
    Posts
    922
    Thanks
    2
    Thanked 12 Times in 11 Posts

    Re: CommandBar.Control (Word XP)

    The method which you are referring to was valid with versions of DMS which employed macro integration or ODMA. Current versions of DMS applications (both iManage and PowerDocs) use COM, and it's a whole different ballgame. It's cleaner integration, but in some respects the end user loses some of the control that was available with previous methods of integration. Despite this, I actually like the COM integration better. The code using the .Execute method on the command bar control was provided directly by iManage, who say it's the only way to "force" a save. Given the nature of COM, that's understandable.

  8. #8
    Super Moderator jscher2000's Avatar
    Join Date
    Feb 2001
    Location
    Silicon Valley, USA
    Posts
    23,112
    Thanks
    5
    Thanked 93 Times in 89 Posts

    Re: CommandBar.Control (Word XP)

    A big advantage of COM is the ability to interoperate with less macro-savvy apps like PowerPoint and Outlook. I created one for OL, and might be going there next month for PowerPoint. (It's not critical, so I keep putting it off.) I would really miss the opportunity to peer inside the code, though; it makes the APIs that much harder to understand if you can't see how they do it.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •