We use cookies to give you the best experience on our website. If you continue to browse, then you agree to our privacy policy and cookie policy. (Last updated on: November 16, 2018).
Unfortunately, activation email could not send to your email. Please try again.
Syncfusion Feedback

Toolbar persistence

Thread ID:

Created:

Updated:

Platform:

Replies:

15387 Jun 17,2004 12:26 AM UTC Jun 21,2004 03:49 PM UTC WinForms 9
loading
Tags: Tools
Lori S. Pearsall
Asked On June 17, 2004 12:26 AM UTC

Is there something I need to do in code in order to get my toolbars to persist their state? I''ve looked through the samples but I don''t see anything. On my MainFrameBarManager, I have AutoLoadToolBarPositions = false, AutoPersistCustomization = true, Enable Customizing = true On my ChildFrameBarManager, I have EnableCustomizing set to true. All of the "BarStyles" have AllowQuickCustomizing set on. When I''m running, I open up the child form and all of my child toolbars are displayed. I then go to the Customize Toolbar and hide two of them. I then close the child form and open it again and all the toolbars are displayed again.

Lori S. Pearsall
Replied On June 17, 2004 05:10 PM UTC

Here''s some more detailed information : 1) I locate the folder in IsolatedStorage that corresponds to my application - verified by identity.date & folder creation date. 2) I delete it 3) I run my application. I verify that a new folder has been created in isolated storage. The Files folder 2 directories down is empty. 4) I bring up a child form. By default, it has three toolbars displayed - this is correct. 5) I go to Customize Toolbar and mark one of the toolbars to not be displayed - it disappears from the display. The Files folder is still empty. 6) I exit the child form. The Files folder is still empty. 7) I exit the application. The Files folder now has a SyncfusionToolsStateInfo.bin file. 8) I run the program again and bring up the child form. THE TOOLBAR THAT WAS MARKED TO NOT BE DISPLAYED IS DISPLAYED AGAIN. What am I missing? Something''s being persisted - it''e either not the toolbar information or it''s the wrong toolbar information.

Administrator [Syncfusion]
Replied On June 17, 2004 06:31 PM UTC

Hi Lori, In your posting you mention: "On my MainFrameBarManager, I have AutoLoadToolBarPositions = false" This property should be set to true. Here is the description of the AutoLoadToolBarPositions Property from the Essential Tools Help: Gets or Sets a value that indicates whether or not to automatically load the persisted toolbar positions when the application is restarted. Can you take a look and update this posting? Regards Arun

Lori S. Pearsall
Replied On June 17, 2004 06:41 PM UTC

Hi Arun, I set AutoLoadToolBarPositions to true and ran all the steps I listed above. I still get the same results. Thanks! >Hi Lori, > >In your posting you mention: > >"On my MainFrameBarManager, I have AutoLoadToolBarPositions = false" > >This property should be set to true. Here is the description of the AutoLoadToolBarPositions Property from the Essential Tools Help: > >Gets or Sets a value that indicates whether or not to automatically load the persisted toolbar positions when the application is restarted. > >Can you take a look and update this posting? > >Regards >Arun

Administrator [Syncfusion]
Replied On June 17, 2004 09:03 PM UTC

Hi Lori We could not reproduce the problem in the XPMenusMDI sample (Tools\samples\Menus Package\XPMenusMDI). Can you post steps to reproduce this behavior in this sample or post a small sample reproducing this behavior so that we can take a look at it. Regards Arun

Lori S. Pearsall
Replied On June 17, 2004 10:32 PM UTC

I''ve pretty much looked at everything - I see no difference. The only other clue I can give is that persistance does work for the one toolbar that is present in the Parent window. It''s the two that only exist in the Child window that ignore the customization settings. Any other things to check??

Lori S. Pearsall
Replied On June 18, 2004 12:56 AM UTC

Here''s a sample - seems to have to do with RegisterMDIChildTypes. I don''t completely understand why I would HAVE to do this call. In addition, I don''t have a default constructor on my child window class so the Register call doesn''t currently work in my scenario. Anyway, a sample is attached ... toolbarproblem_7140.zip

Administrator [Syncfusion]
Replied On June 18, 2004 03:43 PM UTC

Hi Lori Thanks for helping us reproduce this problem. Yes, this is a bug and it has been addressed by the Essential Tools team. It will be fixed in the next release that goes out. If you want a patch version kindly open a Direct-Trac incident. Regards Arun

Lori S. Pearsall
Replied On June 18, 2004 05:56 PM UTC

Hi Arun, Thanks - I was going nuts with this one. Not looking for any concrete dates, but what is the timeframe of a new release? Also, could you give a brief description of the difference between using RegisterMDIChildTypes and not? Visually, what would be the difference? I''ll have two types of windows that can be open and they will each have their own unique toolbar. Thanks, Lori

Administrator [Syncfusion]
Replied On June 21, 2004 03:49 PM UTC

Hi Lori, Calling RegisterMdiChildTypes will explicitly merge the child types even before they become visible. So you do not have to call it if you don''t want this feature in your application. Regards Arun

CONFIRMATION

This post will be permanently deleted. Are you sure you want to continue?

Sorry, An error occured while processing your request. Please try again later.

Warning Icon You are using an outdated version of Internet Explorer that may not display all features of this and other websites. Upgrade to Internet Explorer 8 or newer for a better experience.Close Icon

;