Thinking out loud here… Here's something I never noticed before: It looks like an ASP.NET Repeater doesn't fire OnItemCommand events when ViewState is off for the control. Not sure why this should be, but I'm working on a form where there are several repeaters all of which are reloaded on every.
I have a LinkButton control in the Repeater template with a CommandName and CommandArgument set like this:
<asp:Repeater ID="repLatestItems" runat="server"
OnItemCommand="repLatestItems_ItemCommand">
<ItemTemplate>
<b><asp:LinkButton runat=server ID="lnkNewEntry" CommandArgument='<%# Eval("pk") %>'
CommandName="ShowEntry"><%# Eval("Title") %></asp:LinkButton></b>
<br />
<small>
<i><%# Eval("Entered") %></i><br />
<%# Eval("Abstract") %>
</small>
<br />
<p />
</ItemTemplate>
</asp:Repeater>
With ViewState on, all works fine. Turn ViewState off and the OnItemCommand event is never fired.
I haven't noticed this before because in most apps I tend to use old school links instead (ie. <a href='<%# EVAL("Url")'></a> etc.) for this sort of thing, but in this case the page has a bunch of other state that should be preserved.
What's interesting too is the way the __doPostback event is set up in client code, with the event argument not encoded into the function call:
__doPostBack('ctl00$MainContent$repLatestItems$ctl01$lnkNewEntry','')
Apparently ASP.NET encodes the CommandArgument into ViewState as part of the control values saved and then restores that, but why isn't it using the CommandArgument parameter to make this universally operational? Well, in theory it shouldn't need that since it can deduce the control id and from the command argument.
Oddly enough the same sort of thing works fine in a DataGrid/GridView which has no such issues with ViewState.
Other Posts you might also like