LØST. Problem med gridview event firing

[evgeny]

Hei. Jeg har en gridview. Når jeg klikker på en rad blir ikke GridView1_SelectedIndexChanged eventen kalt direkte men istedenfor blir hele "code behind" kjørt helt fra toppen av der hvor klassen begynner etterfulgt av Page_Load hvor jeg da har databind funksjonen og når Page_Load er kjørt ferdig da kjører denGridView1_SelectedIndexChanged. Med andre ord jeg databinder 2 ganger samme data noe som jeg taper masse tid på. Er dette noe slags bug i .net eller?

 

Please jeg trenger virkelig hjelp med denne.

Endret 10. november 2008 av evgeny

[Manfred]

Det er jo en postback, så hele Page_load'en kjøres på nytt før Event-funksjonen. Legger du en

if(!IsPostBack)
{
}

rundt innholdet ditt av Page_Load, så kjøres ikke dette på PostBack.

[evgeny]

Ja det har jeg funnet ut men da får jeg et annet problem. Jeg har noen variabler som jeg henter fra basen i Page_Load metoden. Disse bruker jeg i GridView1_SelectedIndexChanged metoden. I dette tilfellet har jeg 2 problemer. Hvis jeg henter variablene i if (!Page.IsPostBack) da er variablene lik 0 når jeg skal jobbe med de i GridView1_SelectedIndexChanged. Hvis jeg henter de utenfor if (!Page.IsPostBack) da gjør jeg jobben 2 ganger noe som jeg taper ytelse på.

 

Noen forslag?

 

EDIT: Kanskje jeg kan putte de variablene inn i session objekter? Kan man putte arraylist i session objekter?

Endret 6. november 2008 av evgeny

[Manfred]

Du putter "object" i Session...

 

Session["minVar"] as ArrayList

 

Er det forresten noen grunn til at du bruker ArrayList og ikke List<T>?

[MrEspen]

Eventuelt kan du prøve å bruke scriptmanager og updatepanel slik at du slipper post backs på endel eventer... Har ikke i hodet hvordan det fungerer her og nå, men MSDN har nok endel eksempler.

[Manfred]

atlas, med andre ord...

 

Du kan lese mer om det her: http://www.asp.net/ajax/default.aspx?wwwaspnetrdirset=1

 

Så kan du jo bruke en UpdatePanel eller noe slikt Da slipper du å reposte hele siden.

[Glenn F. Henriksen]

Hvis du vil lagre en variabel mellom postbacks er det flere måter å gjøre det på, avhenging av hvordan variablene brukes og hvor statiske de er.

 

Hvis det er variabler som sjelden endrer seg og som er felles for alle brukere kan du lagre de i Cache eller i Application[] objektet. Forskjellen er at ting du legger i Cachen kan "gå ut på dato" mens ting i Application[] blir værende der så lenge applikasjonen din kjører.

 

Hvis det er variabler som er brukerspesifikke men som sjelden endrer seg kan du legge de i Session[] objektet. Den er separat for hver bruker og varer så lenge brukeren er på siden din (som regel i 20 minutter etter siste sidelasting).

 

Hvis det er ting som bare er gyldige på den siden du er på er det ikke en smart idé å legge ting i Session[], de blir nemlig liggende lenge og dermed bruker du unødvendig mye minne på serveren din. Da er det noen ganger bedre å bruke ViewState. Når du legger ting i ViewState blir det enkodet og lagt med, skjult, på websiden som blir levert til klienten. Ulempen med ViewState er at hvis du legger store objekter i ViewState blir det tilsvarende mer data som skal leveres til nettleseren. Den egner seg derfor best til enkle variabler eller små lister. Aldri legg store og komplekse objekter inn i ViewState (helst ikke Session heller med mindre du vet/tenker over hva du holder på med).

 

Når det gjelder UpdatePanel så er det ett verktøy som kan brukes og misbrukes. Den er veldig kjapp og enkel å bruke (som utvikler) men du får fremdeles en full postback hvor page_load kjøres og i hele siden blir evaluert på serveren, selv om bare noe av dataene sendes tilbake til klienten. Sånn sett vil den ikke hjelpe deg med problemet ditt. Et updatepanel kan og gi deg noen rare effekter på siden din pga rekkefølgen ting evalueres på, det er en fordel å sørge for at siden fungerer fint uten updatepanel først og så legge det på.

 

I tillegg skal du være oppmerksom på at et UpdatePanel er "pratsomt". Det sender mye data frem og tilbake når det oppdateres. I mange tilfeller er det ikke noe problem men med mye innhold skalerer det dårlig og kan bli et ytelseproblem.

 

Hiver meg på Manfred sitt spørsmål, hvorfor bruker du ArrayList isteden for List<T>?

[evgeny]

Du putter "object" i Session...

 

Session["minVar"] as ArrayList

 

Er det forresten noen grunn til at du bruker ArrayList og ikke List<T>?

 

Har ikke vært borti List<T> før. Er det bedre enn arraylist?

[Glenn F. Henriksen]

Har ikke vært borti List<T> før. Er det bedre enn arraylist?

Ja. Bl.a. fordi den er strongly typed og gir i mange tilfeller bedre ytelse.

[evgeny]

Jeg får ikke lagt arraylist som returneres fra webservice til session objektet.

 

Session["mfromList"] = lmresp.fromList as ArrayList;

Denne gir meg Cannot convert type 'object[]' to 'System.Collections.ArrayList' via a built-in conversion

 

Session["mfromList"] = (ArrayList)lmresp.fromList;

Denne gir meg Cannot convert type 'object[]' to 'System.Collections.ArrayList'

 

Please hjelp

 

EDIT: Object obj = lmresp.fromList;

ArrayList myArrayList = obj as ArrayList;

Denne gir ikke feil men myArrayList = null

 

Denne er vrien asa.

Endret 10. november 2008 av evgeny

[evgeny]

Jeg fikk til object to arraylist konvertering. Slik ser det ut:

 

Session["mfromList"] = new ArrayList(lmresp.fromList); //lagrer i session

ArrayList fromList = new ArrayList((ArrayList)Session["mfromList"]); //tilbake fra session inn i arraylist

Endret 10. november 2008 av evgeny

[Manfred]

Jeg fikk til object to arraylist konvertering. Slik ser det ut:

 

Session["mfromList"] = new ArrayList(lmresp.fromList); //lagrer i session

ArrayList fromList = new ArrayList((ArrayList)Session["mfromList"]); //tilbake fra session inn i arraylist

Du bør bruke as i typecasten tilbake.

 

Session["mfromList"] = minArrayList;

(...)

ArrayList minArrayList = Session["mfromList"] as ArrayList;

 

Men igjen: Se på List<T> i stedet for å bruke ArrayList. Det er stort sett bare gamle java-utviklere som bruker ArrayList av gammel vane

[GeirGrusom]

as brukes når en skal caste reference type (altså klasser og interfaces)

(*) brukes når en skal caste primitiver eller klasser som implementerer operators for konvertering.

 

edit:

Merk at "as" returnerer null dersom konverteringen ikke var vellykket.

Endret 10. november 2008 av GeirGrusom

[Manfred]

tja.. Jeg mener strengt tatt at du bør bruke .Parse() eller .TryParse når du skal caste primitiver jeg, da. Så jeg mener at du ikke skal bruke (*) i det hele tatt.

[GeirGrusom]

Hva hvis du skal caste fra decimal til double da?

 

Eller hvis du lager denne klassen:

 

public struct SomeType
{
 public byte a;
 public byte b;
 public static operator short(SomeType val)
 {
return val.a | (val.b << 8);
 }
}

int main()
{
 SomeType tp;
 tp.a = 100;
 tp.b = 500;
 SomeFunctionThatTakesShort((short)tp);
}

 

 

Begge to har sin funksjon mener jeg.

[Manfred]

Ok, da. Jeg kan moderere meg til å si at man bruker Parse/TryParse i de aller fleste tilfeller

 

 

Edit: Parse() er jo da, som GeirGrusom så fint påpekte kun til strings. For alt annet mener jeg at vi har Convert-klassen

Endret 10. november 2008 av Manfred