We Keep Coding

UWP Get Page type from User Control from code-behind

I have a user control that is reused on multiple pages, including MainPage. I would like to perform some logic in the user control if the event happens on the current page for the instance of the user control. The logic is the same no matter what the page is, so I'd prefer not to have the user control invoke a delegate from the parent page.
//Event method in the user control:
private void Dummy_Event(object sender, DummyEventArgs e)
{
// Handle global application events only if this page is active
if (((Frame)Window.Current.Content).CurrentSourcePageType == typeof(/* PAGE TYPE */))
{
//DO STUFF
}
}
In the if statement I'm checking if the application's current page type is equal to the page that this instance of the user control is a child of.
I could do repetitive calls of this.Parent, but even if I do eventually get to a Page element, there's no way of telling which page it is as far as I know.
Does anyone have any ideas?

Things get a bit messy if you make it the responsibility of the UserControl itself to figure out if it is inside the current Page of a Frame. I would follow Mark's suggestion and expose a Boolean property (perhaps IsActive) which you can use to decide whether or not you should handle that event within the UserControl. It now becomes the responsibility of each Page to set this flag inside OnNavigatedTo and to clear it inside OnNavigatedFrom.

Viewstate and controls in ASP.NET

I posted a question a couple of days ago about viewstate and after running some tests I have come to some conclusions/results. Based on these results I have a few questions as to how someone would do certain things.
Here are the results of my tests that I ran:
If usercontrolA is loaded from OnInit of a Page, then his viewstate will be available in OnLoad. All other controls that usercontrolA loads from it's OnInit, will have their viewstate ready in their OnLoad.
If usercontrolA is loaded from OnLoad of a Page, then his viewstate will be available in OnPreRender. All other controls that usercontrolA loads from it's OnLoad, will have their viewstate available in their OnPreRender.
If usercontrolA is loaded from an event (Example: button click. Events fire after OnLoad and before OnPreRender) of a Page, then his viewstate will not be available. All other controls that usercontrolA loades will not have their viewstate available.
So in a perfect world you would always load all controls using situation #1, so that their viewstate is available on their OnLoad. Unfortunately when you need to load a control from a button click or from a OnLoad, is there no way for control to get its viewstate before OnPreRender stage?
I have read a bunch of articles on viewstate and thought I understood it, but working on my current application which loads usercontrols which load other usercontrols, I am having a real hard time with being able to get viewstate on my leaf (last in the chain) usercontrol.
Any suggestions and/or links are appreciated.

I don't think I can add anything that this article doesn't cover.
Look specifically at the Life Cycle Events section.
http://msdn.microsoft.com/en-us/library/ie/ms178472.aspx

It is accepted practice to load dynamic controls in OnInit, so that they get the full control lifecycle. I'm not sure I particularly understand your situation though - if you're loading a control based on a button click, why would it have viewstate at that point? On the next OnInit, you should load the control again (I usually use a page level Viewstate item to track that a particular control needs to be loaded) so that it can restore from Viewstate. Something like:
class Default : Page {
enum LoadedControl { Textbox, Label, GridView }
override OnInit() {
if (IsPostback) {
var c = Viewstate["LoadedControl"] as LoadedControl;
if (c != null) LoadDynamicControl(c);
}
}
void Button_Click() {
var c = (LoadedControl)Enum.Parse(typeof(LoadedControl), ddl.SelectedValue);
LoadDynamicControl(c);
}
void LoadDynamicControl(LoadedControl c) {
switch (c) {
case LoadedControl.Textbox:
this.ph.Controls.Add(new Textbox());
break;
...
}
ViewState["LoadedControl"] = c;
}
}
The slightly more interesting bit, though, is that according to catch-up events - it really shouldn't matter. The callstack for dynamically loading a control looks something like:
Control.Controls.Add(Control)
Control.AddedControl(Control)
Control.LoadViewStateRecursive(object)
Control.LoadViewState(object)
Taking Label as an example, it overrides LoadViewState and pulls it's Text property directly from ViewState. TextBox is similar. So, by my reading, it should be OK to add at any point, and then access ViewState. That doesn't seem to be jive with my experience, though, so further investigation seems warranted.

I'm surprised but interested about your results. When I work with dynamic controls I always add them in Page_Init. Anything else doesn't work. But you are right - how do you do it if you are adding them in response to a button click.
The only way I have found is by examining Request.Form("__EVENTTARGET") collection at PageInit. This contains the control ID of the control that has triggered the postback so for instance a button click. It will of course be qualified by the naming containers it appears in. Once you have identified the 'event' by this method you can add the controls you want.
It is of course all a bit hacky but it's the only way I found of doing these things. It does work.
It's interesting that the ViewState is available on PreRender if you add the controls at Page_Load. But as the above link indicates it too late to help you then. The controls state is rehydrated during the load cycle. If it's not there then your control state or dynamic controls are just going to disappear.

Did you try to use LoadComplete event?
Use this event for tasks that require that all other controls on the page be loaded.
This is fired after PageLoad and all events (ButtonClick, etc.), so your UserControls are are loaded in ButtonClick events, and in LoadComplete their ViewState is already initialized.

Loading ASP.NET user control at run time

I have an ASP.NET user control with a button, and I want to add it to the page when the user clicks a button from another user control. I have created an event handler to the first user control to handle it from the page and add the second user control to a page. Everything is working normally, but the button on the second user control doesn't respond to the event.
I place the second control on RadAjaxPanel
Note: When I add the second user control at design time its working fine.

All dynamically created controls should be added by the end of Page_Init (though sometimes you can get away with them added by the end of Page_Load).
If you're only adding them based on a button click event then you've done this in the event handers which fire AFTER Page_Init and Page_Load in the lifecycle - This is why your events don't fire and why it works fine when you add at design time.
This is because when a button is clicked on the second user control - the whole page lifecycle starts again. The page goes through Page_Load and Page_Init first and your control doesn't get loaded here. So, when the page lifecycle handles the "handle postback events" part, the control no longer actually exists, so the event doesn't fire.
Conversely, when you add at design time, the control exists in Page_Init and Page_Load so is able to handle the postback events from the user control because it already exists in the control tree - if this makes sense.
You need to think how you can restructure so they're added by the time Page_Load has finished at the very latest or it won't work. Without code samples or more detail it's hard to suggest exactly how you might do this. One possibility would be to set it visible instead of loading it outright - but if the control does some 'heavy lifting' on load like database hits or API calls then this might not be suitable for you.
I did something similar. What I did was to load some controls dynamically based on a selection from a DropDownList. If you have a method which loads the control for you, let's call it LoadControls(), then you can do something like this:
DropDownList_Click {
ViewState("LoadControls") = true;
LoadControls()
}
By setting the ViewState variable, you can then indicate Page_Load to load the controls on future postbacks:
Page_Load {
if (ViewState("LoadControls") == "true")
{
LoadControls();
}
}
This has the effect of then loading the control on-the-fly when the event first happens, and then at future times in the lifecycle.

ASP.NET usercontrol: check if usercontrol is visible

My question is somewhat related to this thread: How to avoid Initialization of web user control inside aspx?
The UserControl should only be visible when a button is clicked.
So my usercontrol is set like this:
<example:usercontrol ID="idControl" runat="server" Visible="false" />
<asp:Button ID="showMyControl" runat="server" OnClick="ShowMyControl" /
And the usercontrol itself checks if he's visible:
protected void Page_Load( object sender, EventArgs e ) {
// only execute if the user control is visible
if ( this.Visible ) {
...
}
}
When I click the button I'm setting the property Visible of the usercontrol to true but when the postback occurs the Visible-property in the Page_Load of the usercontrol is still set to false.
My UserControl is probably loaded first and the Visible-property is set afterwards?
Is there an easy way to resolve this?
Thanks in advance!

The Load event of your control, which is being handled by your Page_Load event handler method if I understand correctly, gets fired before the Click event of your button control. Therefore, when the Page_Load method checks this.Visible, the property has not yet been changed because the Click event handler has not yet executed.
For this reason, I think that checking the Visible property of your control would be more appropriate in the PreRender event instead of the Load event.
I'm guessing that you're doing some sort of data retrieval or something that you wish to avoid if the control is not visible. Unfortunately, this sort of issue regarding the page life-cycle and the order in which events fire is sort of a common issue to deal with in ASP.Net programming.
If all of your initialization code can easily be moved into the PreRender event, then great. Problem solved (hopefully). If not (i.e. you need something to happen before the PreRender), you may need to come up with some other mechanism to ensure that your code executes at the right time. For example, you could expose a "SetVisible" method on your control which sets the Visible property to true and then also executes whatever initialization logic is needed. The downside of this is that you can't really guarantee that some code won't just set your control's Visible property to true outside of the SetVisible method that you provide.
Another idea is to actually override the Visible property and perform your initialization logic whenever that property gets set to true.

Put the code which you call in the Control's Page_Load event into the PostBack event. Make sure the button has autopostback set to true.

What you are looking for is the Control.EnsureChildControls method. This method exists for this very situation. It will ensure that all child controls have been created. Then you can set your visible property.

Programmatically adding a user control in ASP.NET

I have a user control that needs to load a child control when a button is clicked.
The trouble is that it has to request the control from another class.
So in the button click event, I call the function to get me my control, and add it to the page, like this:
UserControl ctrl = ExampleDataProvider.GetControl(some params...);
myDetailPane.Controls.Add(ctrl);
The GetControl method looks like:
public static UserControl GetControl(some params...)
{
ExampleDetailPane ctrl = new ExampleDetailPane();
ctrl.Value = "12";
ctrl.Comment = string.Empty;
return ctrl;
}
This isn't working due to the page's lifecycle - the Page_Load of the child control gets fired and its controls are null.
I kind-of know that my approach is wrong and why, but don't know the best way to go about fixing it! Could anyone help?

Dynamic controls must be re-created on every postback, this Article is a good link about how to persist dynamic controls and their state.

If you want to access your control in PostBack or you want to bind Event, you have to create them in CreateChildControls() method.
private UserControl _uc = null;
/// <summary>
/// Creates all controls.
/// </summary>
/// <remarks>All the controls must be created in this method for the event handler</remarks>
protected override void CreateChildControls()
{
_uc = new UserControl ();
this.Controls.Add(_uc);
base.CreateChildControls();
}

Create your control in Page_Init. Then make it visible on your Button_Click event.
(CTRL+C/CTRL+V from some other question I answered last week):
Everything that has to be maintained between page cycles should be declared in Page_Init, not Page_Load.
All the initialization, like adding event handlers, and adding controls should be added during initialization, as the state is saved between page cycles. Handling with the content of controls and the viewstate, should be done in Load.
Check also http://msdn.microsoft.com/en-us/library/ms178472.aspx.
Init
Raised after all controls have been initialized and any skin
settings have been applied. Use this
event to read or initialize control
properties.
.
Load
The Page calls the OnLoad event method
on the Page, then recursively does the
same for each child control, which
does the same for each of its child
controls until the page and all
controls are loaded.
Use the OnLoad event method to set
properties in controls and establish
database connections.

Two possible approaches:
Have the control in the page but not loaded with anything until they click their button. Then you can populate the values in the control. This has the benefit of being within the page life cycle. Note, you can always use the "display: none" style setting for the that your user control is in. Then, as part of the OnClick for the button, you can reveal the div making your control visible.
You could pop up another window, though obviously this has the potential for being blocked by popup blockers.