Why do you need to execute control's events first... could you enlighten us
a bit? Maybe we would offer a different approach.

Signature
RobertK
{ Clever? No just smart. }
> OnInit would be even better. But I really need a way to organize the events
> so that the OnInit event is fired in my custom control first. Is this
[quoted text clipped - 7 lines]
> > RobertK
> > { Clever? No just smart. }
I am producing a user control that partner sites will include in all their
ASP.NET pages. This control is responsible for logging important
information about the request to a database. It is critical that my control
log this data before any of their controls or pages begin to execute for
reasons too complicated to go into. So I want to make certain that my
OnInit event fires before any others on their page.
Technically this particular user control does not produce any HTML output.
This user control actually is a "smart wrapper" of sorts for my class
library. So instead of giving the third party developers several lines of
code to set properties and call methods of in my class library, I'm wrapping
everything that needs to be done into a web control. That way they just
need to register and include the user control in their page, and the control
will take care of the more complicated use of the class library for them.
Is this the right approach to encapsulating complicated calls to a class
library and make it easy for more novice programmers to call?
In any event, if there was a clever way for me to ensure my OnInit event
would fire first that would be great.
Thank you.
> Why do you need to execute control's events first... could you enlighten us
> a bit? Maybe we would offer a different approach.
[quoted text clipped - 15 lines]
> > > RobertK
> > > { Clever? No just smart. }
Robert Koritnik - 30 Jun 2004 09:14 GMT
Normally things are executed this way:
- constructor: page first then all controls
- OnInit: controls first, then the page
- OnLoad: page first, then controls
- other events...
Decide for yourself. If you have the data by the time constructor is called
use that. That's the very first time your control executes any code.
then there is LoadViewState and so many other methods. Check MSDN what else
you could use. Check creating server controls articles.
I suggest you really check some very deep articles, because making good
server controls shouldn't be held as an easy task eventhough it looks like
that.
Check this article on MSDN: "Understanding ASP.NET ViewState" it will
explain many things about this and maybe you'll get another idea (like
inheriting a Page class instead of including your own server control on
every page) I think since your control doesn't have a visualization part I
would create my own class inherited from Page that would do this. Any child
private events are FIRST called on the base class, SECOND on the running
instance itself (ie: Load event).

Signature
RobertK
{ Clever? No just smart. }
> I am producing a user control that partner sites will include in all their
> ASP.NET pages. This control is responsible for logging important
[quoted text clipped - 41 lines]
> > > > RobertK
> > > > { Clever? No just smart. }