UpdatePanel 刷新时 ViewState 丢失？
我没有使用 Session 对象或存储到数据库，而是存储需要持久保存到自定义 ViewState 变量的临时变量。例如，ViewState("MyField1") = 1
当用户点击浏览器 Rrefresh 按钮时，Page.IsPostback 返回 False，ViewState 消失。
我的问题是。如果用户可以通过刷新来消除 Viewstate，为什么还有人使用它呢？
我知道刷新会重新发布最后提交的页面，为什么 Page.IsPostback 重置为 False 并且 ViewState 被吹走？
如果您想创建一个潜在的重复问题，请告诉我，但我在这里阅读了其他帖子，并且它并没有深入...
更新原始帖子：
我现在认为它与执行的回发有关单击 UpdatePanel 内的按钮的结果。有人可以帮助阐明这一点吗？
Rather than using the Session object or storing to the database, I am storing temporary variables that I need persisted to custom ViewState variables. For example, ViewState("MyField1") = 1
When the user hits the browser Rrefresh button, Page.IsPostback is back to False and the ViewState is gone.
My question is. If the user can blow away the Viewstate by refreshing, why would anyone use it?
I know that a Refresh reposts the last submitted page, by why is Page.IsPostback reset to False and the ViewState blown away?
Flame me if you want for creating a potential dup question, but I've read other postings here, and it ain't sinking in...
Update to original post:
I now think that it has to do with postbacks that are performed as a result of clicking on Buttons that are within an UpdatePanel. Can someone help shed some light on this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
当客户端刷新浏览器时，它会重新提交客户端发出的最后一个完整页面请求（可能是GET 或 POST）。它永远不会重新提交 AJAX 请求，例如由更新面板事件触发器生成的请求（“部分页面回发”）。
刷新页面时
Page.IsPostback为false的事实意味着您的原始请求是 GET，因此可能会发生以下情况：1) 在初始请求期间，客户端不向服务器发送任何表单数据 - 因此没有包含视图状态数据的隐藏字段 (了解 ASP.NET 视图状态 非常详细，但如果您想真正了解正在发生的事情，那么值得一读）。在处理此请求时，ASP.NET 可能会将一些视图状态发送回客户端，但原始请求只是一个 URL。
2) 当用户单击 UpdatePanel 中的按钮时，他们会触发部分回发，在此期间
MyField设置为 1。UpdatePanel 更改客户端的视图状态以反映新值。此时，如果用户通过正常方式提交 POST 请求，例如单击按钮，视图状态将包含更新的信息。
但如果用户单击“刷新”，他们会重新提交步骤 1 中的原始请求，但没有表单数据，因此也没有视图状态。
When a client refreshes their browser, it re-submits the last full page request issued by the client (which may be a GET or a POST). It does not ever resubmit AJAX requests such as those produced by update panel event triggers ("partial page postbacks").
The fact that
Page.IsPostbackisfalsewhen you refresh the page means that your original request is a GET, so here's what's probably happening:1) During the initial request, the client sends no form data to the server - hence no hidden field containing view state data (Understanding ASP.NET View State is pretty detailed, but a great read if you want to really understand what's going on). While processing this request, ASP.NET may send some view state back to the client, but the original request is just a URL.
2) When the user clicks a button within an UpdatePanel, they trigger a partial postback during which
MyFieldis set to 1. The UpdatePanel changes the client's view state to reflect the new value.At this point, if the user submits a POST request by normal means, such as clicking a button, the view state will contain the updated information.
If the user clicks 'Refresh' though, they re-submit the original request from step 1, with no form data and therefore no view state.
你在哪里设置你的ViewState？您在哪里重新读取 ViewState 值？也许 oyu 在 ASP.NET 调用 LoadViewState() 方法之前检查其内容。
Where do you set your ViewState? And where do you re-read your ViewState value? Maybe oyu check its content before asp.net calls the LoadViewState() method.
用户点击刷新并使用 updatepanel 将无法很好地协同工作。我想这就是为什么人们说 WebForms 为 Web 编程提供了一个有漏洞的抽象，并且有些人正在转向 mvc。
如果您对迁移不感兴趣，我建议您不要使用 updatepanel 进行太长时间或太大的操作，您可以假设用户可能会刷新页面。将其用于一些小事情，例如当 dropdown1 上的选择发生变化时 dropdown2 项目也会发生变化。
如果您只依赖于视图状态，那么将大量功能包装在一个更新面板中会带来麻烦。
User hitting refresh and using updatepanel will not work together very well. I quess this is why people say that WebForms provides a leaky abstraction on web programming and some are moving to mvc.
If you're not interested in migrating, I'd give you the advice that do not use updatepanel for too long or big operations, where you can assume that user might refresh the page. Use it for small things like dropdown2 items changing when selection on dropdown1 changes.
Wrapping lots of functionality in one updatepanel will cause trouble, if you just depend on viewstate.
你的问题是，“为什么有人会使用它。”
对于您知道是由回发生成的数据，Viewstate 会派上用场。点击刷新并不是回发，而是一个新的请求。
因此，假设您正在浏览数据网格，并且您需要了解有关他们单击的内容的某些数据，在单击事件中，您可以将该数据存储在视图状态中，并在页面生命周期的其他时间或后续发布中处理它背。
ViewState 的优点是它只是嵌入到 HTML 中，因此都是客户端的。由于 SessionState 是服务器端的，如果您在会话中存储大量数据，可能会导致您的 Web 或数据库服务器更加努力地处理这些数据。
希望这有帮助。
Your question is, "Why would anybody use it."
Viewstate comes in handy for data you know is generated by a post back. Hitting refresh is not a post back, but a fresh request.
So lets say you are browsing a datagrid and you need to know certain bits of data about what they have clicked, on the click event you could store that data in the viewstate and process it during other times in the page life cycle, or subsequent post backs.
ViewState's advantage is that it is just embedded into the HTML, so it is all client side. Where as SessionState is server side, and if you store a great amount of data in the session you can cause your web or db server to work harder to handle that data.
Hope this helps.
不知道为什么它有效，但我遇到了类似的问题，并通过将此行放在 form_load: 中解决了
它
Don't know why it works but I had a similair problem and solved it by putting this line in the form_load:
where