<p>I have a (derived) Menu control, that displays a rather large list of items from a custom data source. I need to disable ViewState on the menu to avoid the very annoying "Can't select a disabled or unselectable menu item" when some other control causes the current selection to change on a postback.</p>

<p>Unfortunately, when ViewState is disabled for the Menu, the postbacks generated <em>by</em> the menu aren't raising any events. If I enable ViewState, the OnMenuItemClick event is raised. If I disable ViewState, OnMenuItemClick is not raised. I'm perplexed.</p>

<p>I need to leave ViewState off for the menu, so how can I handle postbacks from the actual menu?</p>

<p>At this point I'm leaning towards using the Menu's Load event, parsing the __EVENTTARGET to see if it's the Menu, and going from there. This would technically process the postback event before it would normally but that's ok, I guess.</p>

<p>Any better ideas?</p>

I've figured out the essence of the problem. Using Reflector we can see the important part(s) of the low level method that handles the actual postback and then raises the event:
```
```
string str = HttpUtility.HtmlDecode(eventArgument);
...
MenuItem item = this.Items.FindItem(str.Split(new char[] { '\\' }), 0);
if (item != null)
    this.OnMenuItemClick(new MenuEventArgs(item));
```
```
As you can see the MenuEventArgs is handed a MenuItem. If one cannot be found in the current Items collection that matches the incoming post data, then the event is not raised. With ViewState disabled, the menu doesn't have any Items (they would have been rebuilt using ViewState). So the event won't be raised.
To work around this, I've told the menu to build itself during Load using the not-yet-updated data (at this point it will be the same as it was at the end of the last request). This is essentially the same as rebuilding the menu from ViewState, so I don't feel bad in regards to performance, or whatever. OnMenuItemClick is then fired as expected. Lastly, during PreRender I tell the Menu to rebuild once again, so it reflects the changes that happened during the postback processing portion of the lifecycle.
I wasted a lot of time on this, so hopefully this info can help somebody else in a similar situation.