Professional UI Solutions
Site Map   /  Register
 
  

Forum

Please Log In to post a new message or reply to an existing one. If you are not registered, please register.

NOTE: Some forums may be read-only if you are not currently subscribed to our technical support services.

Forums » Prof-UIS Tech Support » CustomizeStateLoad/Save questions Collapse All
Subject Author Date
RICHARD ALTON Jan 19, 2011 - 11:11 AM

Hi,


We have 2 longstanding issues with the customise state persistence that I am unsure how best to solve:


1) Being able to save the customisation in a way that the users can maintain their window layouts between versions of our app:


Our state information for the control bar layout and command manager etc is stored using CExtCustomizeStateSave/Load and CExtControlBar::ProfileBarStateSave/Load in the usual way. These functions save binary data into the registry. This causes problems if we, for example, add a new toolbar. The data can only be serialized successfully if the saved data exactly matches the layout of the app. We have got around this for years by setting a #define UI_VERSION X constant in our app, which we increment when we change the layout. When the app loads, if this version differs from the stored one, then I wipe all Prof-UIS registry settings and the app can run without crashing.


This however annoys our users since their layout returns to the default everytime they get a new release of our app. What we would like, is a backwards-compatible version of the state persistence that allows us to maintain existing stored data, yet will also let us save/load any newly added data (toolbars, command customisations, etc). Is there any way you can think we can get around this problem and not have to keep resetting the layouts everytime we make a change? I would suggest maybe an XML based save/load system rather than a binary one would allow for this, and would be backwards compatible?


2) As a follow on from above, we would like to store user-profiles on the server, i.e. keep all state persistence data in a file on the server, so whichever computer a user is working on, they can see their own personal window/toolbar layout. I read that we could use the existing system to write the profile data to a file, which is half the issue, but we would still have the versioning issues as descrived above, where if the file stored on the server is of a different version to the app the user is running, then their settings will all be reset to default.


Any ideas/suggestions as to the best way to solve these issues? I guess probably it would be a major refactor and I may have to write my own XML based version of the state persistence. However I would rather not have to do this...


Thanks.