[Info] Correct way to load a new ribbon from a 2nd assembly?

Mar 27, 2010 at 6:51 PM
Edited Mar 29, 2010 at 3:46 PM

1. Is it necessary to call _ribbon.DestroyFramework() before calling InitFramework() with a [different] ribbon from a second assembly?  ...I'm assuming it is.

2. How "expensive" is it to (re)create a Ribbon object? How "expensive" is it to (re)run DestroyFramework() followed by InitFramework()?  Related to #1, is it reasonable to use DestroyFramework/InitFramework to frequently completely replace the Ribbon?  For scenario, take Outlook 2007/2010 with the left folder view that displays all of the different kinds of Outlook folders and you're cursoring up and down through the different types of folders.  The ribbon changes everytime (or everytime the folder type changes).

NOTE: I can't use Ribbon application modes because this is part of a WinForms application extensibility framework and it works best if each Ribbon is in a separate assembly.

Michael Herman (Toronto)

Mar 27, 2010 at 9:28 PM

Indeed, you must call DestoryFramework before calling again InitFramework.
Also, try to avoid the following common pitfall, you can't call DestoryFramework in an event handler of one of the ribbon items, otherwise you will get an exception.
If you must, open a timer that will invoke the DestoryFramework, after you return from the event handler.

I can't say what you are planning is a "best practice", since Microsoft didn't allow changing the ribbon structure for a reason..
But this will probably work, just make sure you don't reload the ribbon DLLs over and over, to avoid the extra IO. Hopefully for you it will work fast enough...

Mar 29, 2010 at 3:49 PM

Re: I can't say what you are planning is a "best practice", since Microsoft didn't allow changing the ribbon structure for a reason.

Can you explain the latter part of your comment a bit more?   It seems to be that whether you're using application modes or reloading an entirely new ribbon object, it shouldn't make a difference (i.e. modulo performance, etc., using one approach or another is an "implementation detail" ...isn't it?)


Mar 29, 2010 at 8:59 PM

As far as I understand, application modes should be used to allow several static ribbon modes like "Normal mode" and "Print Mode".

I assume that Microsoft noticed they didn't provide a dynamic way to use the application modes thus there is probably a reason behind it.

That being said, I don't work at Microsoft and can't really tell why they limited the API in such a way.