WebPart events not triggered upon first logon

[Paal Berggreen]

I am involved with development of a Portal solution using ASP.NET 2.0
and WebParts. The WebParts framework use the default personalization
providers, and the personalization data thus ends up in the aspnetdb
database (which we have placed on a proper SQL Server, not SQL Server
Express).

Everything works like a charm, with the following exception:

New users in the system have to press links or buttons twice upon their
first logon to the solution in order for the events to fire. The first
time the links or buttons are fired there is a postback, but the event
is not triggered. The second time it works fine.

The WebParts are added dynamically during Page_Load (see code below),
so the reason the events are not firing the first time is most likely
because the events have not been properly wired-up the first time the
page is posted back. At this time there is no record in the asbnetdb
for the user, i.e. the user personalization has not yet been persisted.

However, when the page is rendered after the first click the
personalization data for the user is persisted (with the
aspnet_PersonalizationPerUser_SetPageSettings stored procedure). Thus,
when the page is loaded the second time the web part is instantiated by
the web parts framework, and the events are wired up as they should.

The problem has been isolated in a testpage containing a
WebPartManager, a WebPartZone, and one WebPart that is added
dynamically in Page_Load.

Perhaps the problem could be solved if we could force the web parts
framework to perform the aspnet_PersonalizationPerUser_SetPageSettings
after the first initial rendering of the page, but the best way would
be to have the events wire-up done correctly. Also, I cannot see that
there is any way of forcing the framework to perform the
aspnet_PersonalizationPerUser_SetPageSettings procedure.

Any help to solve this would be appreciated.

The code-behind for this is shown here:

using System;
using System.Data;
using System.Configuration;
using System.Collections;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Web.UI.HtmlControls;

/// <summary>
/// To reproduce problem with events not firing first time:
///
/// 1. Delete all personalization info for the user from the database
/// 2. Open the page in the browser and minimize the WebPart.
/// The event is not triggered.
/// </summary>
public partial class WebPartTest2 : System.Web.UI.Page
{

protected void Page_Load(object sender, EventArgs e)
{
WebPartManager mgr = WebPartManager1;
// only add the webpart if it has not already
// been added by the web parts framework
if (mgr.WebParts.Count == 0)
{
Calendar cal = new Calendar();
cal.ID = "cal1";
GenericWebPart calWebPart = mgr.CreateWebPart(cal);
mgr.AddWebPart(calWebPart, WebPartZone1, 1);
}
}
}


------------------------------------------
Paal Berggreen
www.makingwaves.no
M A K I N G W A V E S
Vaskeriet
Christian Krohgs gate 60
N-0186 Oslo

 

[Guest]

Paal,
Sorry I can't help with two click problem but I offer assistance with one of
these two built into ASP.Net 2.0 solutions for adding webparts to your a
webpage.

I can help with adding webparts to the page at runtime with the
declaritivecatalog or importcatalog. If your interested reply to group or
start new thread.

I can help with entersharedstate where one person adds the webpart to the
page for everyone. If your interested reply to group or start new thread.

Good Luck
DWS

 

[Paal Berggreen]

Hi! Thanks for the tips. Unfortunately this is not the area that we
need help for, but thanks anyway

-Paal

 

[fredrikt.no$pam]

Hi Paal,

Semi-qualified guess:
There is a security restriction preventing personalization to be
updated on get-requests.
when reaching page load after the first minimize click
mgr.WebParts.Count is zero since personalization has been prevented.
So, the part is recreated by your own code in page_load, but this time
personalization is persisted correctly since it is done in a postback.
After the second minimize click occurs the webpart framework creates
the web part from the personalization data hence the postback event can
be handled since the controlId of the part will be the same.

I think what you want to accomplish can be done by overriding
GetInitialWebParts of the webpartzone. It is a method that is used for
populating the zone with static webparts.

Good Luck again!

..f

 

[Robert Bogue [MVP]]

You might (just for giggles) try moving the method from Page_Load to
Page_Init and doing a mgr.EnsureChildControls() before you start adding
controls.

(I don't have a way to test this problem right this second, however, you may
force things to get wired up correctly on the first pass if it's in at
init.)

Rob

 

[Paal Berggreen]

Actually, I found the solution myself, and as is usually the case the
solution is quite simple, when you know where to look.

The solution is to call WebPartManager.SetDirty() after the web parts
have been dynamically added; this forces the web part framework to
persist the personalization data before the page result is returned to
the user.

Everything now works like a charm!


-Paal