Last post Sep 21, 2005 10:16 PM by marcosb
Sep 13, 2005 06:49 PM|marcosb|LINK
WebPartManager1.Personalization.Enabled = false;
Sep 14, 2005 02:01 PM|JoeBerg|LINK
You can programmatically disable the personalization in the Page_PreInit page life cycle. Could you provide more information about the scenario where it throws a null reference exception?
For the <allow .../> tag in the personalization section, the verb means that the specified users can go into the shared scope. Normally that scope is reserved for administrators because users in this mode can change the appearance of the site for all users.
To go in this scope, you can call WebPartManager1.Personalization.ToggleScope() and the WebPartManager.Personalization.Scope property will tell you in which scope you currently are ("User" or "Shared"). If the ToggleScope( ) function is called for a user that cannot
access the shared scope then an error will be thrown. In your case, since you are using users="*", it means that anyone can go in the shared scope and modify the site for all users.
Please see the link below for more information:
Hope this clarifies,
Sep 14, 2005 04:19 PM|marcosb|LINK
My personalizable page has a WebPartManager control that is working fine.
I got a null object when I request the current web part manager, like in the following example (I put EnsureChildControls() just to try to generate the control instance)
2) The attribute personalization-enabled
Sep 14, 2005 05:32 PM|JoeBerg|LINK
This is confusing, I tried the same scenario on the latest build and it works fine. What build # or CTP are you using?
You can set the initial scope declaratively like this:
To get the intellisense on the enabled property you can do like this:
However, "personalization-enabled" should be recognized by the intellisense. The programmatic property is "WebPartManager.Personalization.Enabled".
Hope this helps,
Sep 15, 2005 11:26 AM|marcosb|LINK
Thanks Joe for your useful help.
I'm using the beta 2 release of the visual studio (2005 55603-000-0000016-00821)
As you said that works for you, I dropped a webpartmanager control in another page and it works!. I don't know why the control is not instantiated in the other page. Maybe other controls of the web part framework on this page are playing a role in this issue.
Maybe there is a deeper issue here. Where is the control tree of the page created?. It should be created before the PreInit event?
Sep 15, 2005 01:08 PM|JoeBerg|LINK
The control tree should be available in the OnInit( ) page life cycle; which means that a control can now safely access any child controls.
Please could you provide the code for the page where the WebPartManager is null?
Sep 15, 2005 02:02 PM|marcosb|LINK
Hi Joe, I think I found which is the problem.
But before that, I don't understand why we are trying to access controls in the preinit event if the instantiation of the controls should happen just before the init event?
Now, the cause of the problem.
When we try to access the webpartmanager or any other control in the preinit event, everything seems to be ok. The problem arises when the page has a master page defined, I mean, when the page is a content page.
In this case the controls are not instantiated in the preInit event.
Now, how can we solve this problem? :(
Sep 20, 2005 05:35 PM|JoeBerg|LINK
You are right, the WebPartManager is not instantiated yet in the PreInit of the content page. The work-around is to access the "Master" property before trying to access any control within the content page.
Sep 21, 2005 10:16 PM|marcosb|LINK