I have a site which uses dynamic MasterPages. The selection of the
MasterPage to use is determined by an encrypted QueryString. Session_Start
looks for the presence of the QueryString, decrypts it, and sets up a
Session variable holding the name of the MasterPage to use. The contents
pages interrogate this Session variable in the Page_PreInit method (has to
be done here) and apply the correct MasterPage accordingly.
Works perfectly, until / unless the session times out. I'm checking for this
at the top of the Page_PreInit method using if (Session.IsNewSession) - this
works. If the IsNewSession is true, then the code redirects to a generic
page informing the user that they have been idle too long, and that they
must log in again. Fairly standard stuff.
HOWEVER, the problem I have is that the contents page then continues to load
i.e. its Page_Load fires, even though I've redirected to a different page.
I've worked round this by use of a boolean variable, as follows:
The code is as below:
bool blnTimedOut = false; // fudge variable
private void Page_PreInit(object sender, System.EventArgs e)
{
if (Session.IsNewSession)
{
blnTimedOut = true; // fudge code
Response.Redirect("~/sessionTimedOut.htm", false);
return;
}
this.MasterPageFile = "~/master/" + Session["strSite"].ToString() +
".master";
}
protected void Page_Load(object sender, EventArgs e)
{
// this event fires even though Response.Redirect in Page_PreInit
if (blnTimedOut ) // fudge code
{
return;
}
// rest of Page_Load code
}
Whilst the above most certainly works, I'm wondering if there is a better /
neater / more efficient way of doing this. E.g. is there a property of the
Page object that I can set in Page_PreInit to tell it not to fire any
further Page events...? I've done a trawl through MSDN and Google but have
drawn a blank...
Any assistance gratefully received.
MarkMark,
Don't think so. I say, If it ain't broke, don't fix it!
Peter
--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com
"Mark Rae" wrote:
Quote:
Originally Posted by
Hi,
>
I have a site which uses dynamic MasterPages. The selection of the
MasterPage to use is determined by an encrypted QueryString. Session_Start
looks for the presence of the QueryString, decrypts it, and sets up a
Session variable holding the name of the MasterPage to use. The contents
pages interrogate this Session variable in the Page_PreInit method (has to
be done here) and apply the correct MasterPage accordingly.
>
Works perfectly, until / unless the session times out. I'm checking for this
at the top of the Page_PreInit method using if (Session.IsNewSession) - this
works. If the IsNewSession is true, then the code redirects to a generic
page informing the user that they have been idle too long, and that they
must log in again. Fairly standard stuff.
>
HOWEVER, the problem I have is that the contents page then continues to load
i.e. its Page_Load fires, even though I've redirected to a different page.
I've worked round this by use of a boolean variable, as follows:
>
The code is as below:
>
bool blnTimedOut = false; // fudge variable
>
private void Page_PreInit(object sender, System.EventArgs e)
{
if (Session.IsNewSession)
{
blnTimedOut = true; // fudge code
Response.Redirect("~/sessionTimedOut.htm", false);
return;
}
this.MasterPageFile = "~/master/" + Session["strSite"].ToString() +
".master";
}
>
protected void Page_Load(object sender, EventArgs e)
{
// this event fires even though Response.Redirect in Page_PreInit
if (blnTimedOut ) // fudge code
{
return;
}
// rest of Page_Load code
}
>
>
Whilst the above most certainly works, I'm wondering if there is a better /
neater / more efficient way of doing this. E.g. is there a property of the
Page object that I can set in Page_PreInit to tell it not to fire any
further Page events...? I've done a trawl through MSDN and Google but have
drawn a blank...
>
Any assistance gratefully received.
>
Mark
>
>
>
"Peter Bromberg [C# MVP]" <pbromberg@.yahoo.nospammin.comwrote in message
news:6B9E1F51-8A8C-4545-9C52-B4868DEA43F1@.microsoft.com...
Quote:
Originally Posted by
Don't think so.
OK.
Quote:
Originally Posted by
I say, If it ain't broke, don't fix it!
Well, yeah, but I'm always interested in finding better ways of doing
things...
Maybe there are none in this particular case... There certainly seems to be
no way of one of the "early" Page methods telling the "later" ones not to
fire... This can get annoying if the creation of the page needs to be
aborted in the Page_PreInit, and you subsquently have Page_Init, Page_Load,
Page_PreRender and Page_Unload... :-)
Nil desperandum - it works...
Hmmm.
I suppose you *could* do that, e.g. have a boolean somewhere and the "early"
lifecycle method / event can set this, and your code in the later one would
check for it and only execute certain code if it's true, no?
Peter
--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com
"Mark Rae" wrote:
Quote:
Originally Posted by
"Peter Bromberg [C# MVP]" <pbromberg@.yahoo.nospammin.comwrote in message
news:6B9E1F51-8A8C-4545-9C52-B4868DEA43F1@.microsoft.com...
>
Quote:
Originally Posted by
Don't think so.
>
OK.
>
Quote:
Originally Posted by
I say, If it ain't broke, don't fix it!
>
Well, yeah, but I'm always interested in finding better ways of doing
things...
>
Maybe there are none in this particular case... There certainly seems to be
no way of one of the "early" Page methods telling the "later" ones not to
fire... This can get annoying if the creation of the page needs to be
aborted in the Page_PreInit, and you subsquently have Page_Init, Page_Load,
Page_PreRender and Page_Unload... :-)
>
Nil desperandum - it works...
>
>
>
"Peter Bromberg [C# MVP]" <pbromberg@.yahoo.nospammin.comwrote in message
news:C53DF6B7-E05D-4B2A-B949-FC9E6CB1494E@.microsoft.com...
Quote:
Originally Posted by
I suppose you *could* do that, e.g. have a boolean somewhere and the
"early"
lifecycle method / event can set this, and your code in the later one
would
check for it and only execute certain code if it's true, no?
Er, did you actually *read* the code in my original post...?
That is *precisely* what I'm doing... ;-)
