Forum

I’ve been looking at implementing the customisation for toolbars, menus etc, along with other GUI features (from our current system which doesn’t yet use ProfUIS for most things).

Currently it seems settings related to customisation, as well as toolbar/controlbar positions get saved in the registry under "CURRENT USER". I can see that the key can be changed to say LOCAL_MACHINE etc.

I was wondering what Ideas you had for the ability for a client to customise their setup and have it used the same way over multiple machines? Though some settings might be made per user.

Also will it work to have some settings on a per user basis and some settings on a machine basis.e.g. can you have the menu and toolbar customisation on a per machine basis, but have positions of toolbars and menu statistics as per user.

MFC ofen has problems (as it seems profUIS does too) if certain things are changed (e.g. toolbar removed via code) and then the toolbar position settings are loaded - Is something like this likely to happen if we have different settings stored in the way suggested above.

 

 

Thanks for mentioning the Archive based methods - I think that’s what I want.

On the other issue, is it possible to be saving the customisation and the toolbar locations separately.e.g Have one file (per machine) for the customisation settings, and then have multiple files (one per user) for the toolbar positions. Will this cause problems if I then go and add or remove toolbars, and then swith users - will the other user files be out of sink because a toolbar was added or deleted?

The customization subsystem allows users to create and remove toolbars dynamically (not only change the content of existing toolbars and menus) when the control bar state persistence algorithms require exact matching between the control bars created in the main frame window and the state data for loading. So, you should load the state of the customization subsystem first because this algorithm creates a dynamic number of toolbars and only then load the state of control bars. So, you don’t have any reason to manage the state of these two subsystems independently from each other. But, if you disable creation of dynamic toolbars in the Toolbars page of the Customize dialog, then you can manage two states independently.

Just to give you an idea of the purpose I am asking the question. Our product is often used in a situation where an office or company will customise the application to suit their needs, and then set up all the installations of this to be the same accross all their machines. But they probably want to allow the flexibility of uses choosing their own layout etc.

According to what you are saying, if a change is made to the number of toolbars (and number of items on toolabs?) then I can’t use an out of sync control bar layout state. I am thinking that if I store some unique identifier with the both the archives. If the user makes a customisation change, then the archive for this is saved with a new identifier - I would only save when I detect they make a change. Then when a user loads this new change, and they controlbar state doens’t match, then we just revert to the default layout. They can then save a new controlbar state.

Does this sound like it would work?

Also, do toolbars from a "tear-off menu" cause a problem here?

Also does the loading of the command manager settings dependant on the customisation settings in the same way the controlbar setttings are?

The serialized data format for all the Prof-UIS components does not depend on a Prof-UIS version. So, the same project with customizable toolbars and menus can be compiled with different Prof-UIS versions using 32-bit or 64-bit target. A state saved by a 32-bit application can be loaded by a 64-bit version of the same application and vice versa. But customization subsystem by default requires matching between commands and basic toolbars created in the main frame window and state data. It’s possible to allocate and use dynamic commands as it is demonstrated in the Pluggable sample. This application scans for plugin DLLs and allocates commands for each of them. The number of available DLLs can be different during each next start of the Pluggable sample because it tracks the dynamic plugin commands. It’s also possible to let the ProfAuto library do hard work relating to dynamic command support. This library provides a set of COM wrapper objects for customizable toolbars and menus. This is convenient if you are going to create extensible applications and code plugins using some scripting language which supports COM objects (OLE automation). There is a <span class="newgreen">ActiveScripts</a> sample that demonstrates how to use the active scripting library for running Java Script or VB Script code which modifies customizable toolbars and menus and handles command events. This approach is similar to VBA (Visual Basic for Applications) integration inside MS Office programs.

You will need to use the state persistence of three Prof-UIS subsystems: customize site, control bars and command manager. Let us review all three systems:

1) The following methods of the CExtCustomizeSite class can be used for implementing the state persistence of customization subsystem:

      bool CustomizeStateLoad(
            __EXT_MFC_SAFE_LPCTSTR sSectionNameCompany, // under HKEY_CURRENT_USER\Software
            __EXT_MFC_SAFE_LPCTSTR sSectionNameProduct, // under HKEY_CURRENT_USER\Software\%sSectionNameCompany%
            __EXT_MFC_SAFE_LPCTSTR sSectionNameProfile, // under HKEY_CURRENT_USER\Software\%sSectionNameCompany%\%sSectionNameProfile%
            HKEY hKeyRoot = HKEY_CURRENT_USER,
            bool bEnableThrowExceptions = false
            );
      bool CustomizeStateSave(
            __EXT_MFC_SAFE_LPCTSTR sSectionNameCompany, // under HKEY_CURRENT_USER\Software
            __EXT_MFC_SAFE_LPCTSTR sSectionNameProduct, // under HKEY_CURRENT_USER\Software\%sSectionNameCompany%
            __EXT_MFC_SAFE_LPCTSTR sSectionNameProfile, // under HKEY_CURRENT_USER\Software\%sSectionNameCompany%\%sSectionNameProfile%\%sSectionNameProfile%
            HKEY hKeyRoot = HKEY_CURRENT_USER,
            bool bEnableThrowExceptions = false
            );
      virtual bool CustomizeStateSerialize(
            CArchive & ar,
            bool bEnableThrowExceptions = false
            );

2) The following static methods of the CExtControlBar class can be used for implementing the state persistence of control bars created inside a frame window:

      static bool ProfileBarStateLoad(
            CFrameWnd * pFrame,
            __EXT_MFC_SAFE_LPCTSTR sSectionNameCompany, // under HKEY_CURRENT_USER\Software
            __EXT_MFC_SAFE_LPCTSTR sSectionNameProduct, // under HKEY_CURRENT_USER\Software\%sSectionNameCompany%
            __EXT_MFC_SAFE_LPCTSTR sSectionNameProfile, // under HKEY_CURRENT_USER\Software\%sSectionNameCompany%\%sSectionNameProfile%
            LPWINDOWPLACEMENT pFrameWp = NULL, // need serialize frame’s WP
            bool bSerializeFixedBarsState = true,
            bool bSerializeResizableBarsState = true,
            HKEY hKeyRoot = HKEY_CURRENT_USER,
            bool bEnableThrowExceptions = false
            );
      static bool ProfileBarStateSave(
            CFrameWnd * pFrame,
            __EXT_MFC_SAFE_LPCTSTR sSectionNameCompany, // under HKEY_CURRENT_USER\Software
            __EXT_MFC_SAFE_LPCTSTR sSectionNameProduct, // under HKEY_CURRENT_USER\Software\%sSectionNameCompany%
            __EXT_MFC_SAFE_LPCTSTR sSectionNameProfile, // under HKEY_CURRENT_USER\Software\%sSectionNameCompany%\%sSectionNameProfile%\%sSectionNameProfile%
            LPWINDOWPLACEMENT pFrameWp = NULL, // need serialize frame’s WP
            bool bSerializeFixedBarsState = true,
            bool bSerializeResizableBarsState = true,
            HKEY hKeyRoot = HKEY_CURRENT_USER,
            bool bEnableThrowExceptions = false
            );
      static bool ProfileBarStateSerialize(
            CArchive & ar,
            CFrameWnd * pFrame,
            LPWINDOWPLACEMENT pFrameWp = NULL, // need serialize frame’s WP
            bool bSerializeFixedBarsState = true,
            bool bSerializeResizableBarsState = true,
            bool bEnableThrowExceptions = false
            );

3) The following methods of the CExtCmdManager class can be used for implementing state persistence of the command manager:

      bool SerializeState(
            __EXT_MFC_SAFE_LPCTSTR sProfileName,
            __EXT_MFC_SAFE_LPCTSTR sSectionNameCompany, // under HKEY_CURRENT_USER\Software
            __EXT_MFC_SAFE_LPCTSTR sSectionNameProduct, // under HKEY_CURRENT_USER\Software\%sSectionNameCompany%
            bool bSave,
            HKEY hKeyRoot = HKEY_CURRENT_USER,
            bool bEnableThrowExceptions = false
            );
      bool SerializeState(
            __EXT_MFC_SAFE_LPCTSTR sProfileName,
            CArchive & ar,
            bool bEnableThrowExceptions = false
            );

In all cases there are two types of methods: registry related methods and CArchive-based methods. The registry related methods are based on CArchive-based methods. So, you can serialize the state of each subsystem using a file on disk, a memory buffer or any other external data storage. The StateInFile sample demonstrates how to implement the state persistence for control bars using a file on disk.

Both MFC and Prof-UIS require the exact match between the state data and the set of control bars created in the frame window. So, you can serialize the state of all the subsystems and add some data specific for your application which describes its UI version for detecting very strong improvements.