Forum

Prof-UIS remembers any customized changes to toolbars and menus that a user may have made.  It remembers this info even if they haven’t made any changes (which is fine).

However, if we add a new control to a toolbar or menu, it won’t appear when our users download the new version.  Instead the old state of the toolbar has been remembered.  Also if we remove a control from the program, it is still remembered by the customization stuff, though it may no longer have an icon etc.

We don’t wish to over-write the user’s customization, but we do want changes that we make to show up in new versions.  This must be a common problem.  Is there a standard way to deal with it?

What would be great is if Prof-UIS handled this for us transparently, and I don’t think it would be hard.  All Prof-UIS needs to do is remember not just the current list of controls on a toolbar/menu, but also the original list of default controls.  When the program is run, if the new default list doesn’t match the stored default list, then you know exactly which controls have been removed or added to the program.  The customized state can be maintained, but any changes to the default are also added/removed automatically.

What do you think?  And any alternative solution in the meantime?

Thanks,

Rob.

Not sure about unregistering of old commands.  A command may be removed by us from a toolbar, but kept as a legacy item in the list of registered commands, even if it no longer appears in the interface by default (or at least not on that specific toolbar).

I don’t follow your statement that "Your new app should support all the commands of your previous app (this is important)".  This should not be required.

You just need to store the default arrangement of controls, eg the default set of buttons for a toolbar.  Then if this doesn’t match the new default setup, we know the change is from the developer not the user, and Prof-UIS knows which buttons to add, and which to remove.  Yes, if the user has re-ordered their buttons there’ll be some guesswork as to where new buttons go, but that’s fine.  Also, you know to remove a control if a command ID no longer exists at all (eg user put a button onto a toolbar it isn’t normally on, then developer removes the control).

What about my second post above?  Why after removing the button does it keep coming back?!

Thanks,

Rob.

Still interested in an answer to the above.  In the meantime I’ve been trying to get this to work for one specific case.  Luckily we are deleting an old control in addition to adding a new one, so we are able to recognise when the user’s customized state needs updating based on the presence of the old control.

When a user first uses the new version, which no longer has the old control, their customized state will bring it back regardless.  So after loading the customization, we look for the old control, and if found we replace it with a new one.  I have this working fine for a menu item, but on a toolbar it is doing something very strange.  It works, but even though the old control is no longer in the toolbar when they exit, it STILL writes out the old control into the customized state.  This old control then loads again next time (and our code once again replaces it with the new one).  I don’t get it.  Is the toolbar state cached somewhere and it’s writing out an old cache?  Even weirder, if the user drags some other control into the toolbar, this is remembered correctly in the customization (although it seems to move to a different place in the toolbar when reloaded), but our new control is STILL reverted back to the old one.  I’m pulling my hair out as none of this makes any sense.

To find and replace the old toolbar button after loading the serialization, we use something like this:

int index = bar->CommandToIndex(ID_OF_OLD_CONTROL);
if (index >= 0)
{
    // Delete the old button and add the new one.
    bar->RemoveButton(index, false);
    bar->InsertButton(index, ID_OF_NEW_CONTROL);
}

The toolbar state is loaded/stored using this:

CExtCustomizeSite::CustomizeStateSerialize(archive);

When exiting, I am printing out the contents of the toolbar both before and after the above call, and in both cases it still shows my toolbar containing only the new control.  Yet during the above call it is writing out the old control.  I have confirmed that in CExtCustomizeCmdTreeNode::Serialize() the m_nCmdIdBasic and m_nCmdIdEffective being written out near the top are set to my old control’s ID when writing out the controls of that toolbar.

Please shed some light on what I’m doing wrong.  How is it possible for my old button to keep coming back?!

Thanks,

Rob.

This interesting task is a bit wider than you described. Generally we need to assume all the commands were removed and new version introduces a complete set of new commands. Besides, we also need to determine whether some of basic or user defined toolbars display only old and removed commands. Such toolbars will have no buttons in the new application version and, probably, they should be removed. The same task automatically appears for any submenu in any level.

We think the solution should be different. Your new app should support all the commands of your previous app (this is important) and may introduce some new commands. When the new app loads state of old app, it should know it runs first time over old app and do the following actions:

1) Unregister all the removed commands.

2) Remove all the old basic toolbars.

3) Try to add new commands into those locations in menus and toolbars where they should appear when new app starts first time on a clean computer.

There are several ways to solve the second task. You can try to find appropriate menus and toolbars, then try to find neighborhood commands of new commands and insert new command nodes near them. The same for submenus of any level. But you should understand this task has no an ideal solution because any user can completely reconfigure structure of all toolbars and menus. It’s possible some easier solution can be better than described above. You need to unregister all the old commands in any case. But you can simply display new commands at the end of their toolbars and popup sub menus. Or even more simple, you can simply inform user about UI changes and ask to reset particular toolbars and menus.