none
How to determine if a button is on the ribbon RRS feed

  • Question

  • Hi All,

    I have an existing Outlook addin that was done with VB6. One of the things it does is put a menu item in the Explorer Tools menu to launch an options dialog. A button for the main operation of the addin is added to the toolbar.

    On Outlook 2010, the Tools menu item is put in the Addin tab in the Menu Commands group. The main button is added to the Addin tab in a Custom Toolbars group. This is all well and good.

    In Outlook 2013, the main button is still in the Custom Toolbars group but the Tools->option doesn't appear. I reallise this is because CommandBars are no longer supported.

    I did a new addin with VS2005 VB using extensibility, not VSTO to do the options part of the original addin. It does what I want. On Outlook 2013 my option appears in the Addin tab in its own group as I intended.

    Both addins will be installed together. How do I determine if the older addin placed the option menu on the addin tab when Outlook 2010 is installed so I can prevent my new addin from putting a second, unwanted, entry on the ribbon? I want to use the new addin for the options as a replacement for the old one. I can't just remove it from the old one since it still has to work with Outlook 2007.

    What determines which addin gets connected to Outlook first? If my new one connects first, the button isn't there yet from the old one. I'm trying to avoid modifying the original addin.

    Thanks.

    Don


    Don Rosengrant

    Wednesday, May 22, 2013 2:12 PM

Answers

  • i think in outlook 2010 you can still use CommandBars interface to actually find your button added from second add-in. maybe try to go that way?
    Wednesday, May 22, 2013 4:08 PM
  • Aside from VB6 addins not supporting use in Outlook 64-bit versions, is there any reason you can't use the same addin code to handle all versions from 2007 (or even 2003) up to 2013? I do that with various Outlook addins I still support that were written using VB6.
     
    I use a ribbon reference from Outlook 2007 and check to see what version I'm running under at runtime to see if I need to support the ribbon or command bars in Inspectors and Explorers. If I reference Outlook 2003 as my base version I use Dennis Wallentin's XLIRibbon interface tlb to grab ribbon interfaces and to set up ribbon callback handling. Then I use Dennis's ribbon interfaces if they apply, or else I just use the command bar interfaces.

    --
    Ken Slovak
    [MVP-Outlook]
    http://www.slovaktech.com
    Author: Professional Programming Outlook 2007
    "Don Rosengrant" <=?utf-8?B?RG9uIFJvc2VuZ3JhbnQ=?=> wrote in message news:1e4f9276-3676-4fb9-b80c-c95c62ed3ec4...

    Hi All,

    I have an existing Outlook addin that was done with VB6. One of the things it does is put a menu item in the Explorer Tools menu to launch an options dialog. A button for the main operation of the addin is added to the toolbar.

    On Outlook 2010, the Tools menu item is put in the Addin tab in the Menu Commands group. The main button is added to the Addin tab in a Custom Toolbars group. This is all well and good.

    In Outlook 2013, the main button is still in the Custom Toolbars group but the Tools->option doesn't appear. I reallise this is because CommandBars are no longer supported.

    I did a new addin with VS2005 VB using extensibility, not VSTO to do the options part of the original addin. It does what I want. On Outlook 2013 my option appears in the Addin tab in its own group as I intended.

    Both addins will be installed together. How do I determine if the older addin placed the option menu on the addin tab when Outlook 2010 is installed so I can prevent my new addin from putting a second, unwanted, entry on the ribbon? I want to use the new addin for the options as a replacement for the old one. I can't just remove it from the old one since it still has to work with Outlook 2007.

    What determines which addin gets connected to Outlook first? If my new one connects first, the button isn't there yet from the old one. I'm trying to avoid modifying the original addin.

    Thanks.

    Don


    Don Rosengrant


    Ken Slovak MVP - Outlook
    Wednesday, May 22, 2013 5:38 PM
    Moderator

All replies

  • i think in outlook 2010 you can still use CommandBars interface to actually find your button added from second add-in. maybe try to go that way?
    Wednesday, May 22, 2013 4:08 PM
  • Aside from VB6 addins not supporting use in Outlook 64-bit versions, is there any reason you can't use the same addin code to handle all versions from 2007 (or even 2003) up to 2013? I do that with various Outlook addins I still support that were written using VB6.
     
    I use a ribbon reference from Outlook 2007 and check to see what version I'm running under at runtime to see if I need to support the ribbon or command bars in Inspectors and Explorers. If I reference Outlook 2003 as my base version I use Dennis Wallentin's XLIRibbon interface tlb to grab ribbon interfaces and to set up ribbon callback handling. Then I use Dennis's ribbon interfaces if they apply, or else I just use the command bar interfaces.

    --
    Ken Slovak
    [MVP-Outlook]
    http://www.slovaktech.com
    Author: Professional Programming Outlook 2007
    "Don Rosengrant" <=?utf-8?B?RG9uIFJvc2VuZ3JhbnQ=?=> wrote in message news:1e4f9276-3676-4fb9-b80c-c95c62ed3ec4...

    Hi All,

    I have an existing Outlook addin that was done with VB6. One of the things it does is put a menu item in the Explorer Tools menu to launch an options dialog. A button for the main operation of the addin is added to the toolbar.

    On Outlook 2010, the Tools menu item is put in the Addin tab in the Menu Commands group. The main button is added to the Addin tab in a Custom Toolbars group. This is all well and good.

    In Outlook 2013, the main button is still in the Custom Toolbars group but the Tools->option doesn't appear. I reallise this is because CommandBars are no longer supported.

    I did a new addin with VS2005 VB using extensibility, not VSTO to do the options part of the original addin. It does what I want. On Outlook 2013 my option appears in the Addin tab in its own group as I intended.

    Both addins will be installed together. How do I determine if the older addin placed the option menu on the addin tab when Outlook 2010 is installed so I can prevent my new addin from putting a second, unwanted, entry on the ribbon? I want to use the new addin for the options as a replacement for the old one. I can't just remove it from the old one since it still has to work with Outlook 2007.

    What determines which addin gets connected to Outlook first? If my new one connects first, the button isn't there yet from the old one. I'm trying to avoid modifying the original addin.

    Thanks.

    Don


    Don Rosengrant


    Ken Slovak MVP - Outlook
    Wednesday, May 22, 2013 5:38 PM
    Moderator
  • DamianD

    I can find the control in Outlook 2010 using CommandBars. At least I can find the Tools menu. I have tried searching for the menu item yet. That should be doable.

    Ken,

    Using DamianD's suggestion, I should be able to find and remove the menu item from the original addin and use my new addin for all apps. When I going through postings learning about ribbons, the one on expanding Outlook 2007 for ribbons implied that, which kind of what you are suggesting.

    Which leads me back to my other question. Does anyone know what determines the order addins are connected? If my new one connects first, the menu won't be there yet to remove. The original one will still put up the menu.

    I may modify the original addin to not put up the menu at all. Which leads me to another question. If once the original addin has be run and it adds the menu item, if I comment out the function that adds the menu item and run it again, the menu item is still there. It just doesn't work. This is also the case if the addin is deactivated. If I remove the menu on startup and not call the function that adds it, it does go away. However if my new addin is run, the button is put in the ribbon, deactivated and run again, the button doesn't get put in the ribbon.

    I guess one option would be to modify the old addin to always remove the menu item if it finds it and not put it in. That may be the safer thing to do. I couldn't find anywhere where Outlook is saving the menu item.

    Thanks for the help.


    Don Rosengrant

    Thursday, May 23, 2013 5:43 PM
  • Removing custom ribbon controls from addin A in addin B is not supported at all unless both addin's ribbons share a common xml namespace. Otherwise one addin could ruin another from a competitor. It would be a major security flaw.
     
    You cannot determine which addin will be started first by Outlook, and it will vary from machine to machine.
     
    I don't think your idea will prove to be very realistic out in the wild.
     
    As far as a button created using CommandBars, the best practice is to always declare it as temporary when creating it, and to delete it if it exists on shutdown. That "belt and suspenders" approach prevents UI from appearing due to disabled or uninstalled addins. If a button is permanent that's a poor programming practice.

    --
    Ken Slovak
    [MVP-Outlook]
    http://www.slovaktech.com
    Author: Professional Programming Outlook 2007
    "Don Rosengrant" <=?utf-8?B?RG9uIFJvc2VuZ3JhbnQ=?=> wrote in message news:7a17082f-be71-484f-8f45-0063df148f36...

    DamianD

    I can find the control in Outlook 2010 using CommandBars. At least I can find the Tools menu. I have tried searching for the menu item yet. That should be doable.

    Ken,

    Using DamianD's suggestion, I should be able to find and remove the menu item from the original addin and use my new addin for all apps. When I going through postings learning about ribbons, the one on expanding Outlook 2007 for ribbons implied that, which kind of what you are suggesting.

    Which leads me back to my other question. Does anyone know what determines the order addins are connected? If my new one connects first, the menu won't be there yet to remove. The original one will still put up the menu.

    I may modify the original addin to not put up the menu at all. Which leads me to another question. If once the original addin has be run and it adds the menu item, if I comment out the function that adds the menu item and run it again, the menu item is still there. It just doesn't work. This is also the case if the addin is deactivated. If I remove the menu on startup and not call the function that adds it, it does go away. However if my new addin is run, the button is put in the ribbon, deactivated and run again, the button doesn't get put in the ribbon.

    I guess one option would be to modify the old addin to always remove the menu item if it finds it and not put it in. That may be the safer thing to do. I couldn't find anywhere where Outlook is saving the menu item.

    Thanks for the help.


    Don Rosengrant


    Ken Slovak MVP - Outlook
    Thursday, May 23, 2013 9:13 PM
    Moderator
  • Ken,

    Addin A must be doing the menu as permenant. I haven't seen anything otherwise in the code. Would that be the default, especially with VB6? How is it declared temporary? Or do you mean that by temporary, the addin removes its menu item on shutdown?

    "Removing custom ribbon controls from addin A in addin B is not supported at all unless both addin's ribbons share a common xml namespace. Otherwise one addin could ruin another from a competitor. It would be a major security flaw."

    I'm trying to have Addin B remove a menu item, not a ribbon control, from Addin A, but I would think that amounts to the same thing, correct? Although I don't think a menu item would have the same security protections a ribbon control has, at least in 2007. Maybe it would in 2010 where the menu item is put in a Menu Commands group on the Addins tab?

    If that's the case, in the case of Outlook 2007 where the there is still a toolbar with the Tools menu in the explorer where I want to put the menu item and the menu item seems to be permenant rather than temporary, if Addin A removes its menu item from the Tools menu on startup and Addin B puts one in, if Addin B starts before Addin A, Addin A shouldn't remove Addin B's menu item if they have the same caption which is how Addin A finds its menu item, correct?

    Thanks.


    Don Rosengrant

    Friday, May 24, 2013 1:15 PM
  • VB6 has nothing to do with object model default settings or properties. Those are the same whether it's VB6, VBA, C#, VB.NET, Delphi, C++, etc.
     
    When you add a new CommandBar (CommandBars.Add) or CommanndBarControl (CommandBarControls.Add) the Temporary argument defaults to False if it's not explicitly set. For Outlook it's a best practice to set it as True. That may vary by application, Word ignores that setting and always adds a control as permanent in the CustomizationContext where the control was added (usually Normal.dot).
     
    As you're not concerned with ribbon controls but command bar controls you can remove a control other code added. You just need to get a handle to the control to remove which you'd get by tag or id or whatever idenifying property you have.
     
    The logic of which addin removes or doesn't remove a control under what circumstances is up to you. If I controlled both addins I would never do anything like that. I'd add controls as temporary and delete them on exit from the addin code.
     
    If controls were there from addins that no longer were running I'd delete the Outcmd.dat file, which is where Outlook stored toolbar/menu customizations. The next time Outlook started there wouldn't be those relic, legacy controls.

    --
    Ken Slovak
    [MVP-Outlook]
    http://www.slovaktech.com
    Author: Professional Programming Outlook 2007
    "Don Rosengrant" <=?utf-8?B?RG9uIFJvc2VuZ3JhbnQ=?=> wrote in message news:c35560f9-09b9-4230-b205-e1421f15efba...

    Ken,

    Addin A must be doing the menu as permenant. I haven't seen anything otherwise in the code. Would that be the default, especially with VB6? How is it declared temporary? Or do you mean that by temporary, the addin removes its menu item on shutdown?

    "Removing custom ribbon controls from addin A in addin B is not supported at all unless both addin's ribbons share a common xml namespace. Otherwise one addin could ruin another from a competitor. It would be a major security flaw."

    I'm trying to have Addin B remove a menu item, not a ribbon control, from Addin A, but I would think that amounts to the same thing, correct? Although I don't think a menu item would have the same security protections a ribbon control has, at least in 2007. Maybe it would in 2010 where the menu item is put in a Menu Commands group on the Addins tab?

    If that's the case, in the case of Outlook 2007 where the there is still a toolbar with the Tools menu in the explorer where I want to put the menu item and the menu item seems to be permenant rather than temporary, if Addin A removes its menu item from the Tools menu on startup and Addin B puts one in, if Addin B starts before Addin A, Addin A shouldn't remove Addin B's menu item if they have the same caption which is how Addin A finds its menu item, correct?

    Thanks.


    Don Rosengrant


    Ken Slovak MVP - Outlook
    Friday, May 24, 2013 1:56 PM
    Moderator
  • As previously stated, maybe not clearly, I am moving the Tools->my_option menu and its functionality from Addin A to Addin B leaving the rest of Addin A's functionality there. A button for its main function is on the main toolbar in 2007 and in Custom Toolbars in 2010 and 2013. This is because as you know the menu item doesn't show up at all in Outlook 2013. It is in Menu Commands in the Addins tab in 2010. Since there is already a large install base of Addin A, and the menu was added as permanent, changing it to temporary doesn't help me out.

    So on install of our product of the updated Addin A and the new Addin B, the install will search for outcmd.dat for all the users and delete it. Addin A will just have the call to the function to add the menu item commented out. (Not usually a good idea to delete code. At least not right away.) I could have also had it delete its menu item on startup. Deleting outcmd.dat seems better.

    Addin B will do CommandBars for Outlook 2007 (I will add the menu item as temporary) and ribbon for 2010 and above as you suggested in your initial post.

    Seem like a reasonable approach?

    I appriciate your help since I am new to VB and ribbons.

    Thanks.


    Don Rosengrant

    Friday, May 24, 2013 6:02 PM
  • It should work, but I wouldn't want to guarantee it. There are so many variables involved that it would need comprehensive testing. One variable is the location of outcmd.dat, for example. Depending on Outlook and Windows versions the file could be in various places. 

    Ken Slovak MVP - Outlook

    Friday, May 24, 2013 6:38 PM
    Moderator
  • Would I be better off having Addin A delete its menu item on startup rather than deleting outcmd.dat on install?

    Other than that, I'm creating a new addin to do CommandBars for Outlook 2007 and ribbon for 2010+ and corresponding functionality for the menu item/control so there isn't interaction between them. I'm just not sure where to make the determination of which version is running and to do one or the other. Maybe in Connect.OnConnection? If 2007 setup the command bars and in GetCustomUI for 2007 return Nothing? If 2010+ just let it fly for ribbons not not try to do CommandBars? I'm going back through some of the articles about ribbons I found. I think I saw something about this.

    Thanks.


    Don Rosengrant

    Friday, May 24, 2013 6:59 PM
  • Deleting outcmd.dat is a workaround for getting rid of unwanted customizations. If Addin A creates UI permanently and never deletes it it's a badly written addin. It should create it as temporary and delete it on exit as a belt and suspenders fail-safe.
     
    As has been mentioned previously you cannot rely on which addin will be connected first. You can check in a later event than OnConnection(), such as MAPILogonComplete() to see which addins are connected. However, that event has already fired if an addin is connected by the user after Outlook startup. So nothing is perfect.

    --
    Ken Slovak
    [MVP-Outlook]
    http://www.slovaktech.com
    Author: Professional Programming Outlook 2007
    "Don Rosengrant" <=?utf-8?B?RG9uIFJvc2VuZ3JhbnQ=?=> wrote in message news:e0213fb7-17c5-4af5-bd87-a6bf215832fb...

    Would I be better off having Addin A delete its menu item on startup rather than deleting outcmd.dat on install?

    Other than that, I'm creating a new addin to do CommandBars for Outlook 2007 and ribbon for 2010+ and corresponding functionality for the menu item/control so there isn't interaction between them. I'm just not sure where to make the determination of which version is running and to do one or the other. Maybe in Connect.OnConnection? If 2007 setup the command bars and in GetCustomUI for 2007 return Nothing? If 2010+ just let it fly for ribbons not not try to do CommandBars? I'm going back through some of the articles about ribbons I found. I think I saw something about this.

    Thanks.


    Don Rosengrant


    Ken Slovak MVP - Outlook
    Tuesday, May 28, 2013 1:27 PM
    Moderator
  • Since I am moving the menu item and its functionality to another addin, I can't change how the menu item is created. I have existing installations to deal with. If I were leaving in, I could change it.

    Deleting outcmd.dat may not be an answer since on some systems even the admin may not be able to delete it.

    As you said, no solution is perfect. If I make the label on the new addin different from the old one, then I don't run the risk of deleting the wrong one if the new addin connects first, as that is how I would find the menu item. And that would make the operation of the two addins independant and which starts first not an issue.

    My only other question is where in the new addin to determine version as to CommandBars vs. Ribbon. Like I proposed in my previous post?

    Thanks.


    Don Rosengrant

    Tuesday, May 28, 2013 5:03 PM
  • You can check the Outlook version in the startup code, that's where I do that. Then I set a variable that I can access any time as needed.

    --
    Ken Slovak
    [MVP-Outlook]
    http://www.slovaktech.com
    Author: Professional Programming Outlook 2007
    "Don Rosengrant" <=?utf-8?B?RG9uIFJvc2VuZ3JhbnQ=?=> wrote in message news:ef4d11c1-b2a9-4d05-ad39-d4dc8ebfcc0e...

    Since I am moving the menu item and its functionality to another addin, I can't change how the menu item is created. I have existing installations to deal with. If I were leaving in, I could change it.

    Deleting outcmd.dat may not be an answer since on some systems even the admin may not be able to delete it.

    As you said, no solution is perfect. If I make the label on the new addin different from the old one, then I don't run the risk of deleting the wrong one if the new addin connects first, as that is how I would find the menu item. And that would make the operation of the two addins independant and which starts first not an issue.

    My only other question is where in the new addin to determine version as to CommandBars vs. Ribbon. Like I proposed in my previous post?

    Thanks.


    Don Rosengrant


    Ken Slovak MVP - Outlook
    Tuesday, May 28, 2013 5:08 PM
    Moderator