开发者

Modal dialog and __doPostback Infinite loop

开发者 https://www.devze.com 2023-02-24 22:09 出处:网络
I\'ve got a modal dialog created using Modal开发者_运维百科PopupExtender. There is an UI created in it using Webservices and a JQuery Templates. There is also a hidden ASP.NET button which is called f

I've got a modal dialog created using Modal开发者_运维百科PopupExtender. There is an UI created in it using Webservices and a JQuery Templates. There is also a hidden ASP.NET button which is called from the javascript using the __doPostback() technique. The javascript hides the modal popup and __doPostback is called on the button (which is inside of the ModalPopupExtender)

I use this technique to pass some parameters are from the javascript. The server-side event handler does some processing and transfers to a page (in some cases, back to itself)

This works fine when the page it transfers to is a different one but if it transfers to the same page, the postback happens over and over again until the stack blows.

How do i stop the postback from re-occurring when I postback to the same page. I guess it doesn't happen the first time around because it posts to a different page and the postback is invalidated.

Code samples are difficult to provide as it's a fairly complicated system and it's difficult to break it apart.

It sounds horrible I know, all I want to do, however, it to call a server side function from javascript with some variables. Is there a better way to do this?


Well, you're posting back, so you have server-side control over your markup. Just stick your javascript that does the repost in a container and in the case that the page posts to itself, hide that container so it's not loaded into the page....

That or you could do client cookies or a querystring param. Both might be wonky.


With out a code sample I can only speculate and hopefully point you in the right direction.

When you transfer to a new page the old page (and therefore the javascript on that page) passes out of scope and therefore does not continue to execute. If, however, the page is reloaded and the condition that invoked the __doPostback continues then you have created the circular reference that causes your problem. Before you invoke __doPostback, but while you are still on the client, you need to clear whatever condition might be causing the chain of events.

If you can not uncover what is invoking your event chain then you might consider that instead of transferring back to the same page transfer to a new page (bounce.aspx) which in turn invokes a response.redirect BACK to the page so that it is not a Postback when it is being reloaded, but a fresh instance of the page. (Yes, this is a kludge, but it might be an effective stop gap...)

Cheers,

CEC


Thanks for the responses. I think i've found the solution.

In the server-side callback I was doing this:

setupPage();
Server.Transfer("mypage.aspx", true);

changing it to this:

setupPage();
Server.Transfer("mypage.aspx");

fixes the problem.

SetupPage() stores all of the data in hidden fields and I assumed that preserving the form state would be necessary so that this resided after the transfer. This doesn't seem to be the case as all of the setup I've done in the page before the transfer seems to still be present.

Odd or perhaps I'm misunderstanding something fundamental about .NET

Edit - Yes, I do misunderstand a lot about .NET. It makes my head hurt sometimes.

Thanks for the help

0

精彩评论

暂无评论...
验证码 换一张
取 消