[C#.NET] Session aanroepen in constructor geeft error

[Yucon]

In een webproject heb ik een derived class van System.Web.UI.Page gemaakt. Hieronder staat een gestripte versie om het probleem duidelijk te maken

code:

using System;
using System.Collections;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Web;
using System.Web.SessionState;

using PicApi.Classes;

namespace testpicclient.Classes
{
    public class CustomPage : System.Web.UI.Page
    {
        public CustomPage()
        {
            Version = "1.0.3";
        }

        public string Version;
        
        public void InitPage()
        {

                
            if (System.Web.HttpContext.Current.Session["City"] == null) 
                Response.Write("No such value in session state.");
            
        }

    }
}

Zoals het hier staat werkt alles. De method InitPage() kan ik zonder problemen vanuit form.aspx.cs aanroepen. Als ik echter de code waarin de session uitgelezen wordt verplaats naar de constructor dan krijg ik bij het laden van de pagina een "Object reference not set to an instance of an object" op de regel van de session code.

Ik denk dat komt omdat nu eerst de constructor van de baseclass aangeroepen wordt waarin "iets" gebeurt dat hier mee te maken heeft en dat dat nog niet gebeurd is als de die sessioncode in de constructor van de derived class staat.

Er is makkelijk omheen te werken door die init gewoon zelf aan te roepen maar echt netjes is dat niet. Daarnaast ben ik ook gewoon erg nieuwsgierig naar het waarom.

[ Voor 3% gewijzigd door Yucon op 24-03-2004 15:15 ]

[whoami]

De constructor van de base - class wordt net niet opgeroepen.

Als je 't zo doet, dan wordt de constructor van de base class wel opgeroepen:

code:

public CustomPage() : base()
{
}

[gorgi_19]

Volgens mij is HttpContext.Current niet eens beschikbaar in de constructor van Page.

[Crysania]

waarom wil je het btw in de init() en niet gewoon in de Page_Load()

[pjvandesande]

Helaas kan ik het nu net weer even niet voor je testen. Maar HttpContex.Current is dacht ik net zoals gorgi_19 al zij niet beschikbaar. Maar zowiezo zou ik zo iets niet in me Initialisatie doen.

[gorgi_19]

Sowieso snap ik trouwens niet waarom je een versienummer van een pagina in je codebehind stopt. Waarom gebruik je hiervoor geen Assemblyinfo.vb / Assemblyinfo.cs ?

[Yucon]

questa schreef op 24 maart 2004 @ 20:51:
Helaas kan ik het nu net weer even niet voor je testen. Maar HttpContex.Current is dacht ik net zoals gorgi_19 al zij niet beschikbaar. Maar zowiezo zou ik zo iets niet in me Initialisatie doen.

Lijkt er idd op.. hier ook al wat verder aan het testen. Constructor():base() gebruiken lost het in ieder geval niet op.

code:

    public class TmpPageClass : System.Web.UI.Page
    {
        public string Version;
        public TmpPageClass()
        {
            Version = "1.00";
        }
    }

code:

    public class WebForm1 : Classes.TmpPageClass
    {
        protected string Version;

        public WebForm1()
        {
            Version = "2.0.0";
        }
        
        private void Page_Load(object sender, System.EventArgs e)
        {
            // Put user code to initialize the page here
            

            Response.Write ("this.Version:"+ this.Version + "<br>");
            Response.Write ("base.Version:"+ base.Version + "<br>");
        }

        }

Was idd al eerder erop gewezen dat de constructor van de baseclass niet uitgevoerd zou worden. Maar als bovenstaande code uitgevoerd wordt dan wordt er

code:

this.Version:2.0.0
base.Version:1.00

getoond. Daarom had ik de indruk dat die toch uitgevoerd zou worden. De variabele Version is trouwens niet als versienummer bedoeld maar was het eerste wat me op dat moment inviel om het vullen van variabelen te testen.

Mbt tot de pageload/init: Om eerlijk te zijn kon ik niet goed kiezen. Omdat het uiteindelijk voor userdata gebruikt gaat worden leek me de init de beste keuze zodat deze gegevens de hele pageload beschikbaar zouden zijn.

Maargoed, HttpContex.Current is dus waarschijnlijk niet beschikbaar. Wat zou nu een goede keuze zijn? Een method maken en die met de sessionvariabelen als parameters vanuit de derived class aanroepen lijkt me wel mogelijk maar ook geen nette optie. Het was eigenlijk de bedoeling om deze dingen onzichtbaar in de baseclass af te handelen zodat ze altijd automatisch beschikbaar zouden zijn.

* Yucon gaat er eerst maar eens een nachtje over slapen

[whoami]

Yucon schreef op 25 maart 2004 @ 01:16:
[...]
Was idd al eerder erop gewezen dat de constructor van de baseclass niet uitgevoerd zou worden. Maar als bovenstaande code uitgevoerd wordt dan wordt er

code:

this.Version:2.0.0
base.Version:1.00

getoond. Daarom had ik de indruk dat die toch uitgevoerd zou worden.

Dit heeft helemaal niks met de constructor te maken.
De constructor is er om je object te initialiseren, om geheugen te alloceren voor bepaalde objecten binnen je object bij creatie, etc....
Het is niet omdat je de base() constructor niet aanroept, dat je daarom de inheritance functionaliteit oid zou verliezen.

[gorgi_19]

Yucon schreef op 25 maart 2004 @ 01:16:
Mbt tot de pageload/init: Om eerlijk te zijn kon ik niet goed kiezen. Omdat het uiteindelijk voor userdata gebruikt gaat worden leek me de init de beste keuze zodat deze gegevens de hele pageload beschikbaar zouden zijn.

Even een paar dingetjes..

Je handler voor het Load-event is bedoeld voor het vullen van de controls met data, databinding, etc.

Je handler voor het Init-event is bedoeld om de pagina te initialiseren op een basis niveau; met andere woorden: Je controlcollectie op orde brengen, controls toevoegen, etc. Het heeft ook vrij veel gemeen met CreateChildControls overriden, alleen komt Init nog iets eerder.

Ik snap trouwens ook niet waarom je Response.Write nog gebruikt. Deze komt dan bovenaan de pagina te staan en kent geen viewstate; de state wordt dus niet onthouden. Waarom gebruik je deze?

[Yucon]

gorgi_19 schreef op 25 maart 2004 @ 08:52:
[...]



Even een paar dingetjes..

Je handler voor het Load-event is bedoeld voor het vullen van de controls met data, databinding, etc.

Je handler voor het Init-event is bedoeld om de pagina te initialiseren op een basis niveau; met andere woorden: Je controlcollectie op orde brengen, controls toevoegen, etc. Het heeft ook vrij veel gemeen met CreateChildControls overriden, alleen komt Init nog iets eerder.

Ik snap trouwens ook niet waarom je Response.Write nog gebruikt. Deze komt dan bovenaan de pagina te staan en kent geen viewstate; de state wordt dus niet onthouden. Waarom gebruik je deze?

Heb het lifecycle verhaal nog eens doorgenomen en het is idd wat duidelijker nu. Ik gebruik nu een losse UserInit method die voorin de pageload aangeroepen wordt.

Response.Write gebruik ik niet in echte pagina's maar voor een snel testscriptje zoals hierboven vind ik het wel handig.