By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
458,122 Members | 1,634 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 458,122 IT Pros & Developers. It's quick & easy.

Problem with RaiseCallbackEvent

P: n/a
I am getting some strange behavior when using RaiseCallbackEvent. I have a
form that implements ICallbackEventHandler. During the client callback, a
session variable is set that is used on the following page load. When
debugging through using Visual Studio, everything works fine. When using
Firefox, everything works fine. However, when I view the site outside of the
debugger in IE, it displays incorrect behavior. The Session variable is set
during the client callback, however IE doesn't show that it's actually being
set until the Page_render event is fired. Firefox sets the value in the
session right away. I need the value to be set right away since controls on
the page depend on the vaue in the session variable. By the time Page_render
rolls around, the page has already rendered improperly because the session
variable hasn't been set. Has anyone else encountered this or have any
suggestions? This behavior was not present in beta 2 which the application
was originally built in.
Sep 5 '06 #1
Share this Question
Share on Google+
8 Replies


P: n/a
Small mistake, I meant the the value doesn't get set until the Page_PreRender
event, not the Page_Render event.

"Chris Cap" wrote:
I am getting some strange behavior when using RaiseCallbackEvent. I have a
form that implements ICallbackEventHandler. During the client callback, a
session variable is set that is used on the following page load. When
debugging through using Visual Studio, everything works fine. When using
Firefox, everything works fine. However, when I view the site outside of the
debugger in IE, it displays incorrect behavior. The Session variable is set
during the client callback, however IE doesn't show that it's actually being
set until the Page_render event is fired. Firefox sets the value in the
session right away. I need the value to be set right away since controls on
the page depend on the vaue in the session variable. By the time Page_render
rolls around, the page has already rendered improperly because the session
variable hasn't been set. Has anyone else encountered this or have any
suggestions? This behavior was not present in beta 2 which the application
was originally built in.
Sep 5 '06 #2

P: n/a
if you are doing a callback and a submit at the same time then you are in
trouble. they are both async processes, and the browser does not guarantee
order. if you are using a session manager, then the server serializes page
processing for each session.

-- bruce (sqlwork.com)

"Chris Cap" <cc********@newsgroups.nospamwrote in message
news:14**********************************@microsof t.com...
>I am getting some strange behavior when using RaiseCallbackEvent. I have a
form that implements ICallbackEventHandler. During the client callback, a
session variable is set that is used on the following page load. When
debugging through using Visual Studio, everything works fine. When using
Firefox, everything works fine. However, when I view the site outside of
the
debugger in IE, it displays incorrect behavior. The Session variable is
set
during the client callback, however IE doesn't show that it's actually
being
set until the Page_render event is fired. Firefox sets the value in the
session right away. I need the value to be set right away since controls
on
the page depend on the vaue in the session variable. By the time
Page_render
rolls around, the page has already rendered improperly because the session
variable hasn't been set. Has anyone else encountered this or have any
suggestions? This behavior was not present in beta 2 which the
application
was originally built in.

Sep 5 '06 #3

P: n/a
That may be the case, but it doesn't explain the fact that in .net beta 2
this worked 100 percent of the time in every browser. It also doesn't
explain the fact that this works 100 percent of the time in firefox. If this
were truly a race condition, it would be present no matter what browser I
used and it would occur at random times, not predictably. The value is
populated at exactly the same time in the page life cycle which leads me to
believe that asychronicty is not the culprit.

I appreciate your comment. Are there any other suggestions short of
revamping the entire system?

"bruce barker (sqlwork.com)" wrote:
if you are doing a callback and a submit at the same time then you are in
trouble. they are both async processes, and the browser does not guarantee
order. if you are using a session manager, then the server serializes page
processing for each session.

-- bruce (sqlwork.com)

"Chris Cap" <cc********@newsgroups.nospamwrote in message
news:14**********************************@microsof t.com...
I am getting some strange behavior when using RaiseCallbackEvent. I have a
form that implements ICallbackEventHandler. During the client callback, a
session variable is set that is used on the following page load. When
debugging through using Visual Studio, everything works fine. When using
Firefox, everything works fine. However, when I view the site outside of
the
debugger in IE, it displays incorrect behavior. The Session variable is
set
during the client callback, however IE doesn't show that it's actually
being
set until the Page_render event is fired. Firefox sets the value in the
session right away. I need the value to be set right away since controls
on
the page depend on the vaue in the session variable. By the time
Page_render
rolls around, the page has already rendered improperly because the session
variable hasn't been set. Has anyone else encountered this or have any
suggestions? This behavior was not present in beta 2 which the
application
was originally built in.


Sep 6 '06 #4

P: n/a
Hello Chris,

I think this is possibly an page specific or environment specific issue.
I've just created a simple page which use client-script callback to update
some sessionState value. I could correctly read the and display the updated
session in the postback after the clientscript call.

Would you provide the detailed page code logic on how you update the
session state in callback function and how to read them in sequential
postback?

Also, you can tried the same code logic on some other simplfied page or
other server machine to see whether the same problem remains. Here is my
test code:

===============================
public partial class javascript_ScriptCallBackPage : System.Web.UI.Page,
ICallbackEventHandler
{
protected void Page_Load(object sender, EventArgs e)
{
ClientScriptManager cm = Page.ClientScript;
String cbReference = cm.GetCallbackEventReference(this, "arg",
"ReceiveServerData", "ctx");
String callbackScript = "function CallServer(arg, ctx) {" +
cbReference + "; }";

cm.RegisterClientScriptBlock(this.GetType(),
"CallServer", callbackScript, true);
}

#region ICallbackEventHandler Members

public string GetCallbackResult()
{
return Session["Time"].ToString();
}

public void RaiseCallbackEvent(string eventArgument)
{
DateTime time = DateTime.Now;

Session["Time"] = DateTime.Now.ToLongTimeString();
}

#endregion
protected void btnDisplaySession_Click(object sender, EventArgs e)
{
Response.Write("<br/>Time: " + Session["Time"]);
}
}
=================================

Please feel free to let me know if there is anything I missed or any other
finding you've got.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

==================================================

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.

==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

Sep 6 '06 #5

P: n/a
Steven, the difference between my code and your sample is that I am trying to
access the session value earlier in the page lifecycle. The page I have is
very complex. Here is the basic flow. I set a session vairable from the
client call back like so

public void RaiseCallbackEvent(string eventArgument)
{
Session["selectedIndex"] = eventArgument;
}

That session value is then used to intiliaze an object datasource on a
custom control that sits on that page. This occurs on the object
datasource's load event. The problem is that in Firefox the session variable
is getting set before this, but in IE it's being set afterward. However, if
I run everything in the debugger, it behaves as expected. I do realize that
this is a weird way of passing data around, but it was the only option at the
time it was written.

"Steven Cheng[MSFT]" wrote:
Hello Chris,

I think this is possibly an page specific or environment specific issue.
I've just created a simple page which use client-script callback to update
some sessionState value. I could correctly read the and display the updated
session in the postback after the clientscript call.

Would you provide the detailed page code logic on how you update the
session state in callback function and how to read them in sequential
postback?

Also, you can tried the same code logic on some other simplfied page or
other server machine to see whether the same problem remains. Here is my
test code:

===============================
public partial class javascript_ScriptCallBackPage : System.Web.UI.Page,
ICallbackEventHandler
{
protected void Page_Load(object sender, EventArgs e)
{
ClientScriptManager cm = Page.ClientScript;
String cbReference = cm.GetCallbackEventReference(this, "arg",
"ReceiveServerData", "ctx");
String callbackScript = "function CallServer(arg, ctx) {" +
cbReference + "; }";

cm.RegisterClientScriptBlock(this.GetType(),
"CallServer", callbackScript, true);
}

#region ICallbackEventHandler Members

public string GetCallbackResult()
{
return Session["Time"].ToString();
}

public void RaiseCallbackEvent(string eventArgument)
{
DateTime time = DateTime.Now;

Session["Time"] = DateTime.Now.ToLongTimeString();
}

#endregion
protected void btnDisplaySession_Click(object sender, EventArgs e)
{
Response.Write("<br/>Time: " + Session["Time"]);
}
}
=================================

Please feel free to let me know if there is anything I missed or any other
finding you've got.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

==================================================

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.

==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

Sep 6 '06 #6

P: n/a
Hello Chris,

I've just performed some further test and did find the problem though the
behavior is abit different. Here is my test:

** In client-side code, after I call the script callback function, I submit
the form (through document.form1.submit())

==================
function testcallback()
{
var ret = CallServer(document.getElementById("txtInput").val ue,
'input');

document.form1.submit();

}
=========================
Then,l in the submit postback, the ObjectDataSouce.Load event seems always
get the SessionState in the last request(not the one set in the previous
script callback). Are you doing the similar thing and get the similar
behvior as mine? BTW, in my test machine, it behave same no matter I
use IEor firefox.

It seems the cause of the problem is the script callback function will send
the background httprequest asynchronously, and if we directly peform
postback(like submit the form ) after the script callback function, it will
result such problem.

So far I have tried two means which can workaround this problem:

1) use window.setTimeout to add a delay between the script callback call
and other postback function call e.g.
===================
function testcallback()
{
var ret = CallServer(document.getElementById("txtInput").val ue,
'input');

window.setTimeout("document.form1.submit()", 1000);

}
=====================
2) other means is to add our own postbcack call in the script callback's
receive callback function, this receive callback is executed when the
background httrequest has finished and I think this is a good place to put
seqentual script code. e.g.:

function ReceiveServerData(arg, context)
{
alert("arg: " + arg + ", ctx: " + context);

//do our own postback here
document.form1.submit();
}
This works well on my side(in both firefox and IE6).

Hope this helps.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

==================================================

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.

==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.


Sep 7 '06 #7

P: n/a
Steven, thanks for your help. Let me try that and I'll get back to you.

"Steven Cheng[MSFT]" wrote:
Hello Chris,

I've just performed some further test and did find the problem though the
behavior is abit different. Here is my test:

** In client-side code, after I call the script callback function, I submit
the form (through document.form1.submit())

==================
function testcallback()
{
var ret = CallServer(document.getElementById("txtInput").val ue,
'input');

document.form1.submit();

}
=========================
Then,l in the submit postback, the ObjectDataSouce.Load event seems always
get the SessionState in the last request(not the one set in the previous
script callback). Are you doing the similar thing and get the similar
behvior as mine? BTW, in my test machine, it behave same no matter I
use IEor firefox.

It seems the cause of the problem is the script callback function will send
the background httprequest asynchronously, and if we directly peform
postback(like submit the form ) after the script callback function, it will
result such problem.

So far I have tried two means which can workaround this problem:

1) use window.setTimeout to add a delay between the script callback call
and other postback function call e.g.
===================
function testcallback()
{
var ret = CallServer(document.getElementById("txtInput").val ue,
'input');

window.setTimeout("document.form1.submit()", 1000);

}
=====================
2) other means is to add our own postbcack call in the script callback's
receive callback function, this receive callback is executed when the
background httrequest has finished and I think this is a good place to put
seqentual script code. e.g.:

function ReceiveServerData(arg, context)
{
alert("arg: " + arg + ", ctx: " + context);

//do our own postback here
document.form1.submit();
}
This works well on my side(in both firefox and IE6).

Hope this helps.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

==================================================

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.

==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.


Sep 7 '06 #8

P: n/a
Unfortunately neither of those solutions work. I have an alert() in my
callback return method and that isn't even showing, so I don't know if the
callback return method is getting run before the page posts. It still works
perfectly in FF and not IE

"Steven Cheng[MSFT]" wrote:
Hello Chris,

I've just performed some further test and did find the problem though the
behavior is abit different. Here is my test:

** In client-side code, after I call the script callback function, I submit
the form (through document.form1.submit())

==================
function testcallback()
{
var ret = CallServer(document.getElementById("txtInput").val ue,
'input');

document.form1.submit();

}
=========================
Then,l in the submit postback, the ObjectDataSouce.Load event seems always
get the SessionState in the last request(not the one set in the previous
script callback). Are you doing the similar thing and get the similar
behvior as mine? BTW, in my test machine, it behave same no matter I
use IEor firefox.

It seems the cause of the problem is the script callback function will send
the background httprequest asynchronously, and if we directly peform
postback(like submit the form ) after the script callback function, it will
result such problem.

So far I have tried two means which can workaround this problem:

1) use window.setTimeout to add a delay between the script callback call
and other postback function call e.g.
===================
function testcallback()
{
var ret = CallServer(document.getElementById("txtInput").val ue,
'input');

window.setTimeout("document.form1.submit()", 1000);

}
=====================
2) other means is to add our own postbcack call in the script callback's
receive callback function, this receive callback is executed when the
background httrequest has finished and I think this is a good place to put
seqentual script code. e.g.:

function ReceiveServerData(arg, context)
{
alert("arg: " + arg + ", ctx: " + context);

//do our own postback here
document.form1.submit();
}
This works well on my side(in both firefox and IE6).

Hope this helps.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

==================================================

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.

==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.


Sep 8 '06 #9

This discussion thread is closed

Replies have been disabled for this discussion.