Sys.WebForms.PageRequestManagerParserErrorException 错误的解决办法

从以下英文文档可得出解决方法:用Response.Redirect()或Response.Write()进行URL带参数的页面重定向时出现如题所示的错误。Ajax是无刷新的,而使用Response进行带参重定向时需要刷新页面。所以只须在UpdatePanel下设置“asp:PostBackTrigger”的“ControlID”为指定的控件名称即可,如:
<Triggers>
<asp:PostBackTrigger ControlID="btnSave" />
</Triggers> 

参考的英文文档:

If you've used the Microsoft ASP.NET AJAX UpdatePanel control, there's a good chance you've hit the "Sys.WebForms.PageRequestManagerParserErrorException" error.

What's a PageRequestManagerParserErrorException?

The UpdatePanel control uses asynchronous postbacks to control which parts of the page get rendered. It does this using a whole bunch of JavaScript on the client and a whole bunch of C# on the server. Asynchronous postbacks are exactly the same as regular postbacks except for one important thing: the rendering. Asynchronous postbacks go through the same life cycles events as regular pages (this is a question I get asked often). Only at the render phase do things get different. We capture the rendering of only the UpdatePanels that we care about and send it down to the client using a special format. In addition, we send out some other pieces of information, such as the page title, hidden form values, the form action URL, and lists of scripts.

As I mentioned, this is rendered out using a special format that the JavaScript on the client can understand. If you mess with the format by rendering things outside of the render phase of the page, the format will be messed up. Perhaps the most common way to do this is to call Response.Write() during Page's Load event, which is something that page developers often do for debugging purposes.

The client ends up receiving a blob of data that it can't parse, so it gives up and shows you a PageRequestManagerParserErrorException. Here's an example of what the message contains:

---------------------------
Microsoft Internet Explorer
---------------------------
Sys.WebForms.PageRequestManagerParserErrorException: The message received from the server could not be parsed. Common causes for this error are when the response is modified by calls to Response.Write(), response filters, HttpModules, or server trace is enabled.

Details: Error parsing near 'Hello, World!106|upd'.
---------------------------
OK
---------------------------

If you ask me, this error message is not all that bad. After all, I'm the one that made it :) The details indicate what was being parsed when it decided to give up. You can see the part of the text from my Response.Write(), and immediately after that is part of the special format I keep mentioning.

Why do I keeping getting a PageRequestManagerParserErrorException?

Well, chances are you're doing one of the things mentioned in the error message. Here are the most common reasons and why they don't work:

Calls to Response.Write():
By calling Response.Write() directly you are bypassing the normal rendering mechanism of ASP.NET controls. The bits you write are going straight out to the client without further processing (well, mostly...). This means that UpdatePanel can't encode the data in its special format.
Response filters:
Similar to Response.Write(), response filters can change the rendering in such a way that the UpdatePanel won't know.
HttpModules:
Again, the same deal as Response.Write() and response filters.
Server trace is enabled:
If I were going to implement trace again, I'd do it differently. Trace is effectively written out using Response.Write(), and as such messes up the special format that we use for UpdatePanel.
Calls to Server.Transfer():
Unfortunately, there's no way to detect that Server.Transfer() was called. This means that UpdatePanel can't do anything intelligent when someone calls Server.Transfer(). The response sent back to the client is the HTML markup from the page to which you transferred. Since its HTML and not the special format, it can't be parsed, and you get the error.
How do I avoid getting a PageRequestManagerParserErrorException?

To start with, don't do anything from the preceding list! Here's a matching list of how to avoid a given error (when possible):

Calls to Response.Write():
Place an <asp:Label> or similar control on your page and set its Text property. The added benefit is that your pages will be valid HTML. When using Response.Write() you typically end up with pages that contain invalid markup.
Response filters:
The fix might just be to not use the filter. They're not used very often anyway. If possible, filter things at the control level and not at the response level.
HttpModules:
Same as response filters.
Server trace is enabled:
Use some other form of tracing, such as writing to a log file, the Windows event log, or a custom mechanism.
Calls to Server.Transfer():
I'm not really sure why people use Server.Transfer() at all. Perhaps it's a legacy thing from Classic ASP. I'd suggest using Response.Redirect() with query string parameters or cross-page posting.
Another way to avoid the parse error is to do a regular postback instead of an asynchronous postback. For example, if you have a button that absolutely must do a Server.Transfer(), make it do regular postbacks. There are a number of ways of doing this:

The easiest is to simply place the button outside of any UpdatePanels. Unfortunately the layout of your page might not allow for this.
Add a PostBackTrigger to your UpdatePanel that points at the button. This works great if the button is declared statically through markup on the page.
Call ScriptManager.RegisterPostBackControl() and pass in the button in question. This is the best solution for controls that are added dynamically, such as those inside a repeating template.
Summary

I hope I've answered a lot of questions here and not angered too many of you. We're looking at ways to improve some of these situations in the next version of ASP.NET, but of course there are no guarantees. If you avoid changing the response stream, you're good to go. If you absolutely must change the response stream, simply don't do asynchronous postbacks.

文章来自:http://weblogs.asp.net/leftslipper/archive/2007/02/26/sys-webforms-pagerequestmanagerparsererrorexception-what-it-is-and-how-to-avoid-it.aspx

 

内有如下案例:零件尺寸测量与显示硬币统计骰子点数统计零件孔位数量统计零件瑕疵检测啤酒盖瑕疵检测书签类型检测手机电池正反面识别车牌识别零件孔位矩形标注多目标陶瓷釉面瑕疵检测标注地面裂痕检测标注杂志页排序药物胶囊瑕疵检测VisionPro是康耐视公司开发的一款强大的机器视觉软件,它广泛应用于自动化、生产线检测、质量控制等领域。案例集里涉及到的应用场景,包括零件尺寸测量与显示、硬币统计、骰子点数统计等,都是VisionPro软件在实际工业中的典型应用案例。零件尺寸测量与显示是一个关键的工业应用,通过VisionPro可以实现高精度的尺寸检测,保证零件的合格率,为生产过程的质量控制提供准确的数据支持。使用VisionPro可以对零件的关键尺寸进行自动测量,并实时显示测量结果,极大提高了生产效率。硬币统计作为另一种应用场景,通常用于自动售货机或者银行的硬币处理系统中。VisionPro能够识别不同面额的硬币,并进行精确计数,对于提高金融设备的处理速度和准确性具有重要作用。骰子点数统计则更多应用在游戏、娱乐行业,通过机器视觉技术可以快速准确地识别骰子的点数,为游戏规则的执行提供技术支持。VisionPro在这方面可以实现高准确率的识别,确保游戏的公正性和趣味性。除了上述场景,VisionPro还能够处理多种复杂的视觉检测任务,例如零件孔位数量统计、零件瑕疵检测、啤酒盖瑕疵检测、书签类型检测、手机电池正反面识别、车牌识别、陶瓷釉面瑕疵检测标注、地面裂痕检测标注、杂志页排序、药物胶囊瑕疵检测等。在零件孔位数量统计方面,VisionPro可以高效识别和计数零件上的孔位数量,确保每个零件都符合设计规范。而零件瑕疵检测则用于识别零件表面和边缘的缺陷,保证零件质量。啤酒盖瑕疵检测、书签类型检测、手机电池正反面识别等应用,都需要精确的视觉识别技术,VisionPro在这些领域有着广泛的应用。例如,在车牌识别中,VisionPro可以快速准确地识别车牌号码和相关信息,应用于停车场管理、交通监控等多个场景。陶瓷釉面瑕疵检测标注和地面裂痕检测标注则是VisionPro在质量控制方面的重要应用,通过对陶瓷产品和地面表面的瑕疵进行自动标注,可以帮助生产人员及时发现并处理生产过程中的问题,提高产品的整体质量。对于杂志页排序和药物胶囊瑕疵检测,VisionPro则可以提供高效率和高准确率的视觉检测解决方案,确保产品在包装和分发过程中的正确性和一致性。VisionPro作为一款成熟的机器视觉软件,在处理多种复杂的视觉识别和检测任务上表现出色。它不仅提高了工业生产的效率和质量,还在交通、娱乐等多个领域发挥着重要作用,是现代工业自动化不可或缺的工具。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值