Persisting Customization settings
Printed From: Codejock Forums
Category: Codejock Products
Forum Name: Command Bars
Forum Description: Topics Related to Codejock Command Bars
URL: http://forum.codejock.com/forum_posts.asp?TID=611
Printed Date: 28 September 2024 at 6:01pm
Software Version: Web Wiz Forums 12.04 - http://www.webwizforums.com
Topic: Persisting Customization settings
Posted By: blockwood
Subject: Persisting Customization settings
Date Posted: 08 April 2004 at 10:12pm
|
what is the best way to persist (and retrieve) a user's toolbar customization?
i need to persist the info on either an event trigged when user customizes the toolbar or on application close. I also need to read the persisted values when I recreate the toolbar with code on next application load. i have code in Customization event to load up the controls in customization dialog so users can customize their toolbars. but all is lost when the app. closes and user would have to do it again each time. |
Replies:
Posted By: SuperMario
Date Posted: 08 April 2004 at 11:15pm
|
You can save the settings to the system registry:
Private Sub Form_Load() ‘Create CommandBar, then load settings CommandBars.LoadCommandBars "App Name", App.Title, "Layout" End Sub Private Sub Form_Unload(Cancel As Integer) CommandBars.SaveCommandBars "App Name", App.Title, "Layout" End Sub Or you can save the commandbar settings to a string and place that string in a file. You can them load/save the settings to that file. I can post some code to do this if you don't like the registry version. |
Posted By: blockwood
Date Posted: 08 April 2004 at 11:33pm
| amazingly enough this works perfectly - with two lines of code! i expected user would have to write specific routine to persist and then retrieve. thx again |
Posted By: dajv
Date Posted: 31 January 2005 at 10:46pm
|
A trap to watch out for that I just discovered: the LoadCommandBars/SaveCommandBars functions won't work if you have set EnabledCustomization to False against the *.xcb file in the Xtreme CommandBars Designer application (they do save to registry but the comandbars remain unaffected next time you call LoadCommandBars).
This is regardless of whether you call CommandBars.EnabledCustomization(). Not sure if this is the intended behaviour but its undocumented (until now!  )
|
Posted By: dajv
Date Posted: 01 February 2005 at 12:47am
|
After getting the LoadCommandBars/SaveCommandBars functions to work after discovering the above, I have noticed that in my application, the CommandBars state is only saved every other time SaveCommandBars is called. I am experiencing the following:
(I call LoadCommandBars and SaveCommandBars when my application starts and closes, and I can confirm these calls are being made and not being skipped over by some logic in my application.) 1) I open my application, make a change to the menus and close it. 2) I reopen my application. The menu layout has been saved. I close my application 3) I open my application again, and the menu layout is lost. 4) See 1). After discovering that the CommandBars actually save the customisation configuration partly to the registry and partly to the MyApplication.exe-layout file, I decided to save and load the layout using LoadStateFromString and SaveStateToString. After making this change, the above 4 steps result in the same behaviour as when I was letting CommandBars save it to the registry. I can see that after step 2), the file I write out the string returned from SaveStateToString() is only 2 KB and not ~66 KB as it is after step 1). Any ideas on what might be happening here? Any advice is appreciated. Thanks |
Posted By: dajv
Date Posted: 01 February 2005 at 4:25pm
|
I think I discovered the problem.
I have a generic function that loads the CommandBars since my application makes use of many different CommandBars. In this function I was calling CommandBars.EnableCustomization(), passing whether or not the CommandBar should be customisable. Most of the CommandBars that call this generic function set this to true. In the problem described above, I was talking about a single CommandBars object on a form that always set CommandBars.EnableCustomization() to true via this generic function. I found that if I removed the call to CommandBars.EnableCustomization() the CommandBars were saved correctly every time. EnableCustomization() therefore seems to be to blame. The fix seems to be to avoid using EnableCustomization(). After removing the call to EnableCustomization(), the CommandBars are saved correctly both to the registry and to a file using Load/SaveStateFromString |