Develop Reference

AJAX AjaxFileUpload control not working if parent Custom Control changes visibility

Spent Days trying to figure out why my ajaxFileUpload control was not firing the UploadComplete event and have finally discovered where it is coming from.
Whenever I try to use the uploader, I get a bizarre JS JSON error which was 'ungooglable'.
Anyway, through lots of testing it turns out the error is occurring because the parent user control (.ascx) has property Visible=false by default.
The parent user control is basically an ajax modal which contains a form + the fileuploader.
When the user clicks a button to show the form i set visible=true, then show the modal.
Is this good practice? and Since the ajaxfileupload seems to glitch out when I use that technique of loading the user control, is there another way to go about this without HAVING to load the form when the parent page is loaded?
Thank you for any help!

If I understand your scenario correctly, this is acceptable practice.
What happens when you try to load anything with AjaxFileUpload is complete control lifecycle.
If a control is not visible for any reason then OnPreRender method, which contains valuable code for completing an upload, is not called.
I would say, that many Ajax Control Toolkit controls, including AjaxFileUpload, simply was not designed for scenarios that involve any visibility modification.

Winform app, force execute OnLoad Event when focus is on another tab

I have a WinForm app, the form has TabControl, control has three tabs tabPage1,tabPage2,tabPage3.
The Tab 'tabPage3' is hosting a User defined control which internally has one or more child controls.
Now my problem lies in tabPage3,
I know it is a pure Winforms behavior, until your parent is not activated child controls Onload event won't fire.
I have a requirement to force the Onload event to fire when the focus is on tabPage1, tabPage2. Is there any way to force the Onload event to fire.
I have already visited following links but didn't find any clue. Link Link Link

This is a very unusual requirement, strongly smells like an XY problem. The Load event is heavily over-used in Winforms, a side-effect of it being the default event for a Form or UserControl. One of the behaviors inherited from VB6, the Load event was a big deal in that language. What you want can easily be accomplished by not giving Winforms a choice:
public UserControl3() {
InitializeComponent();
CreateHandle();
}
The CreateHandle() call does the forcing, OnLoad will immediately run. But do be aware that this happens very early, too early to do the kind of things that you'd really want to use OnLoad() or the Load event for. Which are rather limited, it is only truly necessary to discover the actual Location and Size of the control. Anything else belongs in the constructor. Surely including the code that you now run in OnLoad().
Strongly favor using the constructor instead.

I had a similar problem for a previous project, for my needs I managed to just iterate over every tab page in the forms constructor (or possibly OnLoad I can't remember) and then reset the index back to 0 before ever showing the end user.
Something similar to:
for(int i = 1; i < tabControl.TabCount; i++)
tabControl.SelectTab(i);
tabControl.SelectTab(0);

Understanding RegisterStartupScript and postbacks

I was wondering if anyone could clear the confusion for me. I am trying to implement drag and drops of controls through j query.
There is an init JavaScript function client side which makes all the controls of a certain class draggable and droppable.
The controls are created dynamically code behind.
The controls are recreated every post back even partial ones.
My problem was that these controls were losing there draggable and droppable property after post-backs, so to fix it, I started registering scripts code behind using RegisterStartupScript with a different key whenever an event was fired which would recreate the controls. Can any body shed some light to it and explain why do I need to register a script every time when a page loads. Is this normal or am I missing something.
Thanks.

When you do a partial postback that updates particular html elements, those elements are recreated and therefore lose their javascript event bindings. The startup script recreates those bindings.

sharepoint webpart with many usercontrols

I have created sharepoint 2010 visual webpart in VisualStudio2010 with three user controls (.ascx). I want to dynamically change usercontrol in the webpart by clicking some button at currently loaded usercontrol. The main problem consist in the fact that buttonClick event is handled only after execution CreateChildControls method (where I try to get needed usercontrol using ViewData). Could anyone please help me to solve this problem?

Lee's response is basically right and may work well for you. However, you should not just use __doPostBack and rely that it will be always "magically" there for you. This method and variables mentioned by Lee are internal to ASP.NET and they are not meant to be used directly. Also, if you do not place any postback-ing control on your page this method will actually not be generated and your code calling it would fail.
Luckily, the code to cause and handle a generic postback is very simple. Instead of using built-in event handlers of input controls (which need to be constructed before being triggered - hence the call to CreateChildControls before your handler is called) you would target the postback to the Web Part itself:
public class MyWebPart : WebPart, IPostBackEventHandler {
protected override void CreateChildControls() {
Control clickable = ...; // Create a clickable control.
// Get JavaScript expression to send postback "test" to "this" web part.
var postBack = Page.ClientScript.GetPostBackEventReference(this, "test");
clickable.Attributes["onclick"] = postBack + "; return false";
Controls.Add(clickable);
}
void IPostBackEventHandler.RaisePostBackEvent(string eventArgument) {
if (eventArgument == "test") { // Recognize and handle our postback.
...
}
}
}
The GetPostBackEventReference will generate the necessary JavaScript expression for you. (And actually, just calling it makes the __doPostBack "magically" appear on the page.) The RaisePostBackEvent will be called between OnLoad and OnPreRender. Make sure not to cause child controls be created before that (by calling EnsureChildControls, for example, or by any other means). If you need multiple postback-ing controls the eventArguments parameter will let you differ among them.
You need the postback triggers in your user controls and not directly in the Web Part. I showed it in the Web Part just to keep it simple. You can put the result of GetPostBackEventReference to any control providing you use the right Page and Web Part instances when calling it.
--- Ferda

A way to do this would be have the button call a javascript function that in turn calls the following:
__doPostBack('LoadControl', 'ControlName');
You can then use the server variables __EVENTTARGET and __EVENTARGUMENT to find out which control to load within your CreateChildControls event handler.

I had that problem too.
Add this to the event handler (after executing your code inside the handler)
this.Page.Response.Redirect(HttpContext.Current.Request.Url.AbsoluteUri, true);
Regards,
Pedro

The page lifecycle for controls(order constructed from a page)

For example, lets say I have a page and 2 custom controls on that page. During what event on page do these controls get constructed. When does their page_init get called?
Also, for these 2 custom controls, do they both get constructed before either of the page_init events get called?
I've done some testing with a debugger and such, but I'm wanting a definite answer to these questions. I'm not wanting to make code that works only sometimes.

The official page in the documentation describes the page lifecycle in details, but a picture is worth a thousand words :
If I understand correctly, controls are constructed between the PreInit and Init of the page. Thus, controls' Init methods are called before the page's Init method.
According to the schema, Construct and FrameworkInitialize are called on each control before the Init event are fired, which means that all controls should be constructed and available when entering a specific control's Init method.