[1.0 Preview] DirectEvents do not always retain viewstate

[michaeld]

Unfortunately I can't provide a sample that demonstrates this behavior because the code is very large at this point and spans multiple files. However, what I can say is that in two separate code pages with a direct event, the server-side code has no viewstate and the control values are not available in the DirectEvent postbacks.

In one scenario, I have no problem. I have a page with a user control ascx that is in the aspx of a page and direct event gets called and the serverside control's .Text values are accessible. However, in another case, they are always null. Both are wrapped in formpanel controls

Are there any general guidelines anyone can provide to help debug why viewstate would not be available that I can try?

I have to work around this problem with a DirectMethod but I still do not understand why. Is it possible there have been bug-fixes in the SVN that are not present in the preview that may address issues related to something like this?

[Nojj02]

Just passing by... Had this happen to me before. I believe it's either your

EnableViewState="true"

in your page or web.config file or

AjaxViewStateEnabled="true"

in your ext:ResourceManager

[michaeld]

Yeah, I spent all day with these settings only to find out it did not remedy. I've matched both pages code as closely as I could and still, one works; the other doesn't regardless of these settings. It's quite strange.

[michaeld]

Today, I came upon the solution. I was going over more closely the differences between the two pages. I noticed in one I had the Microsoft ScriptManager control loaded and the failing one did not, so I inserted the ScriptManager. It wasn't the ScriptManager that was causing the problem, but by adding it, a page compilation warning came up that exposed the issue. The issue was that I did not have a <form runat="server"> on the broken page. I removed the ScriptManager, put in the form, and things worked.

I hope this follow-up helps someone else down the road because ext.net doesn't warn that it requires a top-level form, but if you value-access during ajax postback, it must be present.

[geoffrey.mcgill]

I hope this follow-up helps someone else down the road because ext.net doesn't warn that it requires a top-level form, but if you value-access during ajax postback, it must be present.

The <form runat="server"> is not required in the latest v1.0 SVN build. Although would need a test case to confirm for your scenario.

Hope this helps.