This thread was one of those where we were discussing the issues with User Control reusability. Eventually the fixes Vladimir made in 2.4 and the insights I made along the way lead me to being able to create the new Delete-and-render model I posted in User Extensions.
To start to answer your question, the original topic of this thread is about UserContent in a loaded control. The redundant call issue was remedied. The ID issue, I believe I resolved by asserting IDModes explicitly.
But the topic evolved into other issues related to UserControl reusability when attempting to render entirely new User Controls in a DirectEvent/Method. I describe why I had to create the DirectRendering property because Ext.Net has no way to indicate a 3rd mode where the UserControl's Page lifecycle calls Page_Load and you actually want the Page_Load to bind control data.
Typically, in a standard reloading of a page in a DirectEvent/Method, User Controls that are statically bound in the presentation layer or are explicitly dynamically added in the Page_Load lifecycle may not need to be bound because the DirectEvent/Method being called does not require the heavier binding cost of all controls to complete its purpose/function. Typically one tests X.IsAjaxRequest and skips around the binding. That is, it's not always necessary to do all the binding of all controls every time a DirectEvent/Method is fired so it makes sense to
However, I had cases where the DirectEvent/Method was responsible for rendering a totally new UserControl and that was triggering it's Page_Load. In that case, while in the DirectEvent/Method, you actually want the binding of the control to happen before it's rendering because its created during the DE/M. If the developer does the typical test of X.IsAjaxRequest, it will incidentally skip the binding which is not correct. That's why I created DirectRendering and IsAjaxRequestNotRendering properties so that instead in Page_Load I could test
This property returns true only if DirectRendering==false and X.IsAjaxRequest==true so that the User Control can bind the control even though it is inside the DirectEvent/Method, just like it was an original render (GET). [in other words, bind if !X.IsAjaxRequest or (X.IsAjaxRequest and DirectRendering)].
Vladimir said my implementation wouldn't work in parallel mode. I never got the clarification of the scenario why. I suspect it has to do with async modes now popular with latest versions of MS MVC and WebForm Asynch Pages which might make sense as I use Context.Items which may change by the time it actually returns. I'm not sure that's actually true though without looking more closely the page life-cycle between the 1st pass and the 2nd reenter. I'm pretty sure that the Page_Load events called after the original DirectEvent/Method are within the same thread though.
Anyway, so to answer your question, close it if I'm right about that last claim. Keep it open if Vladimir has more to add.
But since 3.0 is now on the docket, it's really time for you guys to look at the 3rd mode I've raised as an issue and look at it as a design concern. There are really 3 modes - 1. Original Load/Refresh (GET), 2. DirectEvent/Method (POST), and 3. DirectEvent/Method (POST) but now while rendering a new User Control that will call its Page_Load (which btw may have its own user controls it's rendering too).
And in most cases, the developer needs to ask/test one thing. Do I bind or exit in Page_Load? In the 1st case yes, 2nd case no, and 3rd case yes. It might even be that the developer may need to know which of the 3 modes it's actually in.