Private, protected, public hvor og hvornår?

Page_Load er ikke det samme som sidens constructor, men er en af de faste metoder som kaldes automatisk i en websides "livscyklus".
Overordnet set foregaar det i denne raekkefoelge:
- constructor
- OnInit
- Page_Load
- OnPreRender
- Render

Afhaengig af hvad du oensker at tjekke eller paavirker paa siden, skal du vaelge at override den relevante metode.
Hvis du vil vide mere om denne "livscyklus" kan jeg anbefale Paul Wilsons artikel: http://authors.aspalliance.com/PaulWilson/Articles/?id=6

Page_Load behoever saa vidt jeg har testet ikke at vaere protected, men kan godt noejes med at vaere private, saadan som f.eks. Visual Studio ogsaa opretter den default.
Det haenger sammen med at aspx-"klassen" ikke er en egentlig selvstaendig klasse og den heller ikke nedarver fra .cs-"klassen" i traditionel objektorienteret forstand.

dgivoni>> hvad er det for noget pjat... jo, aspx-siden bliver kompilet til en normal klasse, og den kan sættes til at arve fra en anden klasse på fuldstændig normal OO-vis.

At Page_Load er en af de faste metoder der kaldes er også en sandhed med modifikationer. Det er rigtigt at eventen Load bliver trigger't, og at metoden OnPageLoad bliver kaldt. Hvis du bare laver en Page_Load-metode skal du

1) Slå AutoEventWireUp til
2) Lave en eventhandler til Page.Load og koble den på sin Page_Load-metode

ang. private, public og protected så er grunden til at eventhandlerne til de forskellige events er private den, at

1) Page_Load er private fordi at eventhandleren bliver lavet i "cs"-klassen, og derfor også vil blive udført herinde
2) Det samme gør sig gældende for knapperne. Når du dobbeltklikker på en knap bliver eventhandleren lavet i "cs"-klassens OnInit-metode, og vil derfor også blive udført herinde. Der er altså ingen grund til at den er pulic eller protected. Havde du derimod SELV lavet eventhandleren ved at påføre parameteren OnClick på din <asp:button>-kontrol, så blev du nødt til
  1) Hvis metode skal være private skal den laves i "aspx"-classen, da den vil blive kaldt herfra
  2) Hvis du vil have metoden i din "cs"-klasse skal den være public eller protected, da, som sagt, at den vil blive kaldet fra "aspx"-klassen.

cyberfessor>> der er ingen grund til at blive nedladende, hvis du ved bedre. Jeg skriver kun, hvad jeg selv tror er rigtigt, saa hvis du kan laere mig noget er du velkommen.
Men jeg skrev nu ikke at aspx-klassen ikke kunne nedarve fra andre klasser, men at den ikke nedarver fra codebehind (.cs-klassen) paa normal vis.
For lige at referere til en artikel paa MSDN:
"When the HTTP runtime module is pointed to this ASPX page, it analyzes the @Page directive. If the Src is present, then it loads the given code-behind file. Next, after a successful compilation, the HTTP runtime utilizes the content of the Inherits directive to get the name of the class from which the current page must be instantiated."
aspx-klassen er altsaa en instantiering af .cs-klassen ikke en nedarvning. Der er forskel

sorry, jeg glemte lige referencen
http://www.msdn.microsoft.com/library/default.asp?url=/msdnmag/issues/01/08/cutting/toc.asp

det var skam heller ikke min mening at være nedladende.

Efter at have læst artiklen du referer til må jeg sige, at jeg ikke helt kan finde ud af om han har svært ved at bestemme sig, eller hvordan det vitterligt hænger sammen.

Det er rigtigt, at han siger at koden bliver en del af siden: "treated as an integral part of the page".
Senere nævner han dog ordet nedarve: "The Inherits attribute represents the code-behind class for the page to inherit from."

Jeg må sige at jeg fik ikke alverdens ud af den artikkel :/

Hvis det første er sandt, hvordan kan man så have en metode på sin aspx-side der hedder det samme som i sin cs-fil. Og hvis du, som jeg kom med et eksempel på, gør brug af en metode i cs-filen på din aspx-side, så skal den metode enten være public eller private. Hvis cs-klassen bliver kørt som en del af siden, så burde det jo være underordnet. Alt opfører sig altså som at aspx-siden og cs-filen bliver compilet som to selvstændige klasser hvor aspx-klassen arver fra cs-klassen på normal vis.

Ok, du har ret i at det er lidt uklart... Jeg vil se om jeg kan finde andre referencer, der forklarer sammenhaengen bedre.

her er der en tekst der underbygger min "teori":

Even an ASPX page with no code on it gets turned into an instance of the System.Web.UI.Page class. The page is parsed by the ASP.NET engine when it is first requested, and then its JIT compiled version is cached in the Temporary ASP.NET Files folder as long as the application is running and the .aspx page hasn't been changed. Since the ASPX page is always instantiated as an object, you can modify its parent class and have it inherit from a class of your choice, provided that your class eventually inherits from System.Web.UI.Page. You can also have different pages set references to the class files of other pages, which makes possible some very interesting sharing of items.

http://www.eggheadcafe.com/articles/20030518.asp

hehe, det begynder at blive lidt sjovt (underligt) det her.
Jeg har fundet flg. artikel:
"The code-behind model entails that a separate class file is used to hold all the code bound to the page. This class inherits from Page and constitutes the effective base class for the aforementioned dynamically generated class that represents the .aspx resource in execution. In other words, if you use code inline, the page is represented by an object derived from Page; otherwise, it will be represented by an instance of a class derived from the code-behind class."

http://www.developer.com/net/csharp/article.php/3087791

men det haenger jo ikke rigtig sammen med at metoder og variable skal vaere protected eller public for at blive tilgaaet fra inline-koden paa .aspx-siden

Jeg er lidt forvirret nu...

dgivoni>> jo, det passer jo fint med, at en metode skal være protected i cs-klassen for at du kan få fat i den fra aspx-klassen, da den jo netop nedarver fra cs-klassen, og protected som bekendt betyder at kode i samme klasse og alle base-klasser kan tilgå metoden/field'et.

men ja, du har da ret i at der findes en del modstridende forklaringer. Om en aspx-side bliver compilet til en klasse hvis den ikke har noget kode i sig eller ej vil jeg ikke begynde at diskutere for det ved jeg ikke noget om. Men om aspx-klassen nedarver fra cs-klassen, det mener jeg ikke der er den store tvivl om at den gør.

Jeg vil takke for jeres tid, det har været spændende at følge diskutionen :-)

Jeg havde forstillet mig at i skulle del pointne, hvad siger i til det?

cyberfessor: smid lige et svar.

ok, jeg mente at det ikke passede med min teori om at det _ikke_ er en selvstaendig klasse nedarvet fra codebehind-klassen.
Saa jeg maa jo nok give mig paa det punkt...

det er helt fint med mig

ogsaa med mig da. Og mange tak :)