If you have access to deriving from the Page class, then you can override
protected virtual void RaisePostBackEvent(IPostBackEventHandler sourceControl, string eventArgument);
in order to know which control will get their IPOstBackEventHandler.RaisePostBackEvent method called. This happens directly before the event is raised.
If you can't do that, you'll have to kinda poke at the form name/value collection.
If the control used __doPostBack to postback, then __EVENTTARGET will have the UniqueID of the cause of the event.
Otherwise, you'll have to cycle the names in the collections, call Page.FindControl on those names, and see if any implement IPostBackEventHandler. That would indicate a control using normal form submit.
The problem with snooping the request variables is that these things aren't guarenteed to stay the same across versions of the framework. They may change the mechanism in the future.
And now we get to the "Enter pressed" issue. Here's the deal with that... When the user presses enter while in, say, a textbox... most browsers cause a submit. With some page configurations, the browser will just kinda choose a button which it decides will the button "clicked". Sometimes it doesn't, and just posts the data without adding a "target" button. In the case of it adding a target button, the above ways of determining the button will work. However, if the browser decides that no button will be the target, then as far as asp.net is concerned, NO control caused the postback, and no IPostBackEventHandler.RaisePostBackEvent will be invoked. In this case, there is no way to know which textbox the user was in at the time or the intent of the user.
This is the reason I created my
DefaultButtons control. To make sure that some button, and in fact the "correct" one, will be considered the postback button.