I'm in the process of converting an ASP.Net webform into a User control and there an event that now says
no suitable method found to override
the event code causing the compile error
protected override void OnPreInit(EventArgs e)
{
//do some stuff
base.OnPreInit(e);
}
Is there any equivalent for a user control?
The OnInit override is available. The User Control Lifecycle on MSDN should help you in determining which event to correctly override. In any case what are you trying to achieve?
No. You'll have to use Init. I cannot think of anything I've ever done in PreInit that couldn't be done in Init just as well.
http://msdn.microsoft.com/en-us/library/system.web.ui.usercontrol_events.aspx
Related
in our asp.net webforms application, we dynamically load usercontrols into placeholders. In order to retain changes across post-backs, our page-life-cycle is a little more complex than usual. We ALWAYS restore the previous control structure in pageInit in order to successfully load our viewstate. Only then do we clear the placeholder and load a new control into it.
This unfortunately means an entire life-cycle both for the old AND the new usercontrol, including server-side-processing of the old module's entire .ascx markup-file.
Now my question: Is there any possibility to minimize server-side processing of the old module, as it never gets sent back to the client (i.e. it's server-side rendering is completely unnecessary). What I'd ideally want to achieve is a sort of "light-weight" loading of a usercontrol, when it's only purpose is restoring vewstate information without it ever reaching the client.
The goal of the exercise is performance optimization.
Any hints, ideas or suggestions appreciated!
I have resolved code running in webcontrol lifecycle events of dynamically added controls by simply checking if the control was visible (http://msdn.microsoft.com/en-us/library/system.web.ui.control.visible.aspx)-
protected void Page_Load(object sender, EventArgs e)
{
if (this.Visible)
{
//Your code here
}
}
If you have any methods that aren't triggered by a page lifecycle event, and have to be triggered by a user action, such as-
protected void Button1_Click(object sender, EventArgs e)
{
//Do something
}
This can safely be left as is, the method code will not be run until the control is added to the page and the action is triggered.
Although the visibility check doesn't feel especially elegant, it's probably the best way to deal with auto wired events on dynamically loaded controls.
I'm working on an application and I would like to use Ajax to partially render part of web page instead of full post back. So I use scriptManager and updatepanel but I have an error in JS sys is not defined. I took a look in generated JS code and it seems that no Ajax client side framework has been loaded by scriptmanager, no reference at scriptressource.
I created a website by using vs2010 template to test ajax and all works fine but in web.config I don't found any difference. Is it a known problem?
Solution:
After comment and uncomment different part of my code i found that is my objectdatasource which cause the problem... ObjectDataSource use function instance to retrieve business object but since i use class properties as argument of my "select" objectdatasource function i need to define current instance of my page as object instance (1) but when work is finished is also disposed by objectdatasource .... :) i stop disposing process by using event "ObjectDisposing" (2) ...
(1)
protected void OdsRecordObjectCreating(object sender, ObjectDataSourceEventArgs e)
{
e.ObjectInstance = this;
}
(2)
protected void OdsRecordObjectDisposing(object sender, ObjectDataSourceDisposingEventArgs e)
{
e.Cancel = true;
}
bye !
I have a question why we can only add dynamic control using LoadControl.
For example:
public partial class wucReportParam : System.Web.UI.UserControl
{
protected void Page_Load(object sender, EventArgs e)
{
wucDate() ctrl = new wucDate();
pnl.Controls.Add(ctrl);
}
}
When in the page_load method of wucDate, the child control of wucDate is null but when i use the following method:
public partial class wucReportParam : System.Web.UI.UserControl
{
public Report Report;
protected void Page_Load(object sender, EventArgs e)
{
ctrl = (wucDate)LoadControl(#"Reports\wucDate.ascx");
pnl.Controls.Add(ctrl);
}
}
In the page_load method of wucDate, the child control of wucDate is not null.
Is anyone could explain to me why asp .net don't create any child control of wucDate when i using contructor ??? Thank you
When dynamically loading a user control, it is important to ensure that the standard ASP.NET page event pipeline is initiated and progresses normally. When you use the new operator to create an instance of a user control, that user control is not properly added to ASP.NET's event system. If the events (Init, Load, PreRender, etc.) to not fire, then your control will never function properly. That is why it is necessary to use LoadControl, as that will make sure that the instance of your user control is created properly and attached to ASP.NET.
Apparently, using LoadControl with typeof (or GetType) has the same problem as using 'new' where the child controls are not initialized. Using LoadControl with a string to the ASCX file works.
Does not initialize child controls.
LoadControl(typeof(MyReport), null);
Works!
LoadControl("Report.ascx");
The initialization of the controls inside a User Control is driven by the ASCX file. Using only "new SomeControl" will not cause this initialization to run, and even if it did, all the design (markup) in the ascx file would be lost.
Remember that the class "wucDate" is only the base class which the full user control inherits from. It's not the same class as you'll get when using LoadControl("wucDate.ascx").
And to be honest, LoadControl has not much, if anything, to do with the page life cycle. That part is handled when you add the control to the container's Controls collection.
As I recall, it pertains to how ASP.NET constructs page components at run time. In ASP.NET although your pages have a class which is defined in your code-behind file, their types don't truly exist until run time. Like a page, although you have a control defined the wucDate type isn't created until it is included at run time. For this reason, the control must be loaded with LoadControl in order to both initialize the type and properly run in through the page life cycle.
This is to the best of my memory so if I'm incorrect here please let me know.
I'm currently working on several custom ASPX server controls. Of course these controls do also expose events. Now one possibility is to register a handler in the code, more specifically in the page where the custom server control resides...like
protected void Page_Load(object sender, EventArgs e)
{
myCustomControl.Click += new ....
}
But how do I have to expose the event in my server control code s.t. I can declare these event handlers directly on the ASPX code (from the Property Editor), similar as you can do it on the Button's click event??
Thanks a lot,
Juri
You do just that...
If you have a public event on your ASCX Control called PropertyChanged
then it'll be available declaritively on your Control as OnPropertyChanged
<ctl:MyControl ID="abc" runat="server" OnPropertyChanged="abc_PropertyChanged" />
Have you tried just making them public events?
This MSDN article does a good job explaining how to do this unfortunately it is more complicated than it seems like it should be.
[1]: http://msdn.microsoft.com/en-us/library/aa719907(VS.71).aspx/".NET Framework Developer's Guide"
In ASP.NET, if I override a page lifecycle event, should I call its base method before or after doing my work? Does it even matter?
protected override void OnPreRender(EventArgs e)
{
// My code goes here
base.OnPreRender(e);
// Or here
}
Yes you should care. Let's say for a moment that you need to insert a new base class in all of those pages. To me it's easier to just go ahead and call the base methods than have to do a lot of refactoring later.
Then again, maybe you don't need to do that.
EDIT
Based on the edit to the question here's some more info:
Yes, you should care. Sometimes you want the base classes method to fire before yours (in case of constructors), and sometimes you want it to fire after yours (destructors).
It may mean the difference between whether a property or object is available or not at the time your code gets to it.
The "OnEvent" methods in the asp.net event model merely wrap the actual event calls (in this case, the "PreRender" event). So the only thing you need to decide is "do I need to call the event before or after I do my work"?
The answer is, it depends on what the code is doing as to if it should go before or after.
As another said, if it is constructor stuff it should go before. Destructor should go after. To give a more concrete example, if you have code that processes the page and loads content, fills drop downs, and fills labels and such then you would want that to happen before any code that looks at what is pre-populated and determines visibility or business rule logic that has to do with the data on the page.
I think it's a good idea to call them just on principle. It may be true that in the framework version you're currently using there's no code in the base class methods, but who knows about future versions. Also, separation of concerns would dictate that code you write that derives from Page not assume the Page class doesn't do anything but raise the PreRender event in its OnPreRender method.
There is no single rule. I can provide you an example. My ASP.net webapp uses a NHibernate transaction opened by the master page and commited/roll-backed by it when the page ends.
Well, I MUST initialize the transaction as early as possible in the OnInit method (Master has no OnPreInit like Page), otherwise user controls cannot access the transaction until Page.Load.
The same rule applies for commit. Controls may want to update objects in the last phases of their life-cycles, then I must close the transaction as latest as possible in the Unload method, or even in the disposer!
So... in my case...
void OnInit(EventArgs e) {
transaction = session.BeginTransaction();
base.OnInit(e);
}
void OnUnload(EventArgs e) {
base.OnUnload(e);
try{
transaction.Commit();
} catch {}
}
void OnError(EventArgs e) {
base.OnError();
transaction.Rollback();
}
I would suggest you a general rule: if your page's design contract involves creating and destroying resources to be used by controls between a certain event range (ie. after Load and before PreRender), init the resource as late as possible before the event is fired, and destroy it as early as possible after the final event is fired
If you're going to call the page base methods anyway, you can use
protected void Page_PreRender (object sender, EventArgs e) {...}
rather than
protected override void OnPreRender(EventArgs e) {
base.OnPreRender(e);
...
}