j000rn

* Override OnCreateChildControls. Lag kontrollene her. Ikke i konstruktøren. Hekt deg også på eventer som OnClick, etc her. Hvis du skal ha flere kontroller som i menyen din f.eks. kan det være greit å se på OnCommand (+ properties CommandName, CommandArgument) også.

* Ved uthenting av properties (f.eks. hvilken som er valg,etc) huske å kjøre EnsureChildControls først.

Husk at kontrollen din "restarter" for hver request. Derfor må du for hver request lage alle kontroller på nytt igjen. For å bevare state i kontrollen bruk ViewState eller ControlState.

Vel... du kan finne den første repeateren og bruke den istedenfor den navngitte....

public void ShowMenuItems(Object sender, RepeaterItemEventArgs e)
{
	if (e.Item.ItemType != ListItemType.Item && e.Item.ItemType != ListItemType.AlternatingItem)
			return;

	Repeater rep = RecursiveFindControl(e.Items,typeof(Repeater)) as Repeater;
	if( rep == null ) throw new ArghException("Argh! En eller annen håpløs designer har fucket opp og fjernet repeateren!!!!  :@   ");
	rep.DataSource = etc.....;
}

private Control RecursiveFindControl(Control ctrl, Type t)
{
	foreach(Control c in ctrl.Controls)
			if( c.GetType().Equals(t) )
					return c;
	foreach(Control c in ctrl.Controls)
	{
			Control res = RecursiveFindControl(c, t);
			if( res.GetType().Equals(t) )
					return res;
	}
	return null;
}

Ikke testet, men om det er noen småfeil klarer du nok å fikse dem selv....

btw; Se på koden min og se at jeg snur om på den første IF setningen og bruker return. Ved å gjøre det på denne måten vil du få mer ryddig og lesbar kode.

Hvorfor ikke bruke Session til dette? Da har ikke bot'n mulighet til å "hacke" timestampen din i det heletatt....

Btw; legge til 2 timer blir jo bare tøys, da vil jo bare bot'n oppfatte det som +2 tidssoner :-P Hvis det skulle vært noe poeng må du jo f.eks. legge til 2 dager ellerno....

Ja, eller enda enklere med WebClient.

Istedenfor å bruke Fidler er det ofte like greit å bare bruke view source i IE/Fx for å se hva som blir sendt frem og tilbake. TamperData i Fx er også et genialt plugin for dette.

Jeg veit det er "for kids", men om du har null erfaring er det en gangske god start.

 

http://msdn.microsoft.com/en-us/beginner/bb308756.aspx

Den var jo genial

class PleaseSayYo
{
 static void Main()
 {
	   Console.WriteLine("Yo!");
	   Console.ReadLine();
 }
}

si at du heller får bannet ip'en 12 timer etter 2 fails da, er ikke krise. dessuten bruker vel de fleste musen når de trykker send uansett? Men nå skal trådstarter få ha tråden sin for seg selv

Dårlig gjordt å banne IP'n som jeg sitter på jobb og deler med 4000 andre. Hvis en av de andre på jobb blir sperret så skal ikke jeg få lov til å browse siden din???

Vennen min som hjelper meg kan kun 2005

2005/2008 er jo prikk like...

 

Ikke når det gjelder coding, tror jeg..

Jo. Det er noen tillegg i 2008, men man må ikke bruke det nye. Å jobbe på samme måten som man gjorde i 2005 går helt fint.

Uttalelsen vitner egentlig om at vennen din kan ganske lite, tror jeg.

VB5???? Du vet at den er fra 1997. Det er kommet 5 nyere versjoner etter denne!

Last ned gratis VS2008 (med VB.Net 9.0) fra http://www.microsoft.com/Express/.

Du vil nok få mer hjelp her med en versjon som ikke er over 10 år gammel.....

Bruk av "HASTER" i emnetittelen er etter min mening brudd på alminnelig netikette / folkeskikk på nett. Tror heller ikke du får hjelp noe raskere på den måten.

 

Werner

Enig. Jeg syntes det er litt frekt, og lar som regel være å svare på slike tråder. Dette er første gangen jeg har svart på en sånn tråd btw :!:

Send med URL'n som skal redirectes tilbake til i querystring.

eller...

Response.Redirect( Request.UrlReferrer, false );

Men referer er valgfritt for browseren å sende, så jeg ville heller brukt den første metoden...

btw; det er god vane å bruke "false" som parameter i Redirect. Da vil det ikke bli kastet en ThreadAbortException(?) på serveren.

//Setting new mode
Persons("Manfred").Sarcasm = FALSE

System.Diagnostics.Process.GetProcessesByName("Manfred")[0].Kill();

:!:

BlueEAGLE: Forstod ikke så mye av linken din eg :/

Linken var bare tull og har ikke noe med det du spurte om. Se heller på System.Diagnostics.Process som jeg sa.

Klassen du leter etter heter:

System.Diagnostics.Process

MyClass MittObject = new MyClass();
MittObject = Session["Objektet"] as MyClass;

Først lager du et nytt objekt. Og så overskriver du dette med det du har i Session.

Hørtes det lurt ut? :!:

MyState m = new Mystate;
try
{
 m = (MyState)Session["MyState"];
}
catch
{}
return m;

Nja, egentlig betyr det:

if( Session["MyState"] != null && Session["MyState"] is MyState )
return (MyState)Session["MyState"];
else
  return new MyState();

Unngå bruk av try/catch hvis du kan gjør det på en bedre måte

System.IO.DriveInfo?

Å lagre hele siden (med kontroller og alt mulig) i Session blir bare tøys. Bruk heller eksempelet mitt fra igår, eller gjør sånn som dette:

internal class MyState
{
 private MyState() //private slik at den ikke får lages utenifra.
 {}

 // En haug med properties her (private field + internal property).
// ....

internal void SaveState()
{
	 HttpContext.Current.Session["MyState"] = this;
}

internal static MyState GetState
{
	 get
	{
		   return (HttpContext.Current.Session["MyState"] as MyState) ?? new MyState();
	}
}
}

Providere som er støttet allerede:

* Inproc (IIS ram) - default - Raskeste, skalerer ikke, forsvinner ofte på grunn av restart av IIS worker process. Bør ikke vare for lenge (default 20 min) på grunn av at det bruker minne.

* State Server (iIS ram på en annen maskin) - Treigere, skalerer litt, forsvinner kun hvis serveren restarter.

* SQL Server - Treigest, skalerer bra. Kan sette til å vare "uendelig" om du ønsker.

I tillegg kan du programmere dine egne. F.eks. XML filer ja, selv om det hørtes utrolig lite effektivt ut...

Jeg sa som default så kjører Session på IIS. Du kan også sette opp en separat IIS server som alle de andre bruker for å lagre sessions, eller du kan bruke SQL Server som session state server.... Du kan tilogmed lage din egen Session state provider hvor du selv velger hvordan objektene skal lagres

Poenget er at man har mange valg, og det kanskje lønner seg å tenke litt igjennom fordeler og ulemper før man setter igang

Uansett så lenge du har abstrakther "Session" koden ut i 1 fil som i første eksemplet mitt så blir det jo enklere å evt. forandre i fremtiden.... + de andre fordelene jeg nevnte.

Du nevnte at jeg kunne lage STATIC variabler og at dette ville bli delt med hele applikasjonen på tvers av brukere? Betyr dette at jeg f.eks. kan lage en statisk LIST<> som inneholder eksempelvis påloggede brukere som vil kunen ses av alle som ser på siden?

Jepp. Men litt avhengig av hva du skal bruke det til ville jeg heller vurdert å bruke en database. Husk at IIS kan finne på å "resirkulere" web'n din, den kan kræsje, etc. I tillegg er static per. maskin, så om du skal bruke load-balancing senere kan det være et problem.

Som default ligger Session i RAM i IIS, slik at det ikke trenger å bli serialisert.

ViewState blir automatisk serialisert for deg.

Om du skal legge objekter i cookies, hidden felter, sende over nettverket, lagre i fil eller database, etc så kan du serialisere dem (til XML eller binær).

Alt kan puttes i Session ja. Greit å unngå å putte kontroller der, objekter som har åpne ressurser (database, fil, nettverk, etc --- egentlig alt som implementerer IDisposable), eller data som tar veldig mye minne.

Betyr det at et objekt umulig kan leve mellom to web sider?

Objektene dine kan leve i f.eks. Session , Application (obsolete - bruk static), static, cache, filer, databaser, på andre maskiner, på browseren, etc. Men de kan ikke leve "mellom to web sider" nei...

ViewState kan brukes for å lagre objektet, sende det til browseren, som sender det tilbake, og lastes av ASP.Net igjen. Men det fungerer kun ved postback på samme side.

For hver eneste postback kan du se det som om applikasjonen starter på nytt. Derfor må alle objekter instanseres på nytt og verdier settes inn. Mye av dette gjør ASP.Net for deg automatisk, men uansett kan det være greit å tenke seg at du lager et Windowsprogram og for hver knapp du trykker på eller dropdownboks du endrer så avsluttes programmet og starter på nytt - og alt må lastes inn igjen... Nesten slik fungerer ASP.Net under panseret.

Du kan sende verdier/"objekter" mellom 2 postbacks/sider. Her har du 3 måter å gjøre dette på; Form post, querystring og cookies (+ andre som ikke blir brukt så ofte - headere, andre post typer, etc).

Ikke så mange valgmuligheter som du ser Session er egentlig bare en cookie som refererer til en viss sted i minnet(/fil/sql server,etc).

Med de 3 måtene kan du serialisere objekter og sende dem mellom sidene. ViewState/ControlState gjør dette automatisk for deg innenfor 1 side.

Det VIKTIGSTE er å ha minst 3 ord. At overskriften faktisk skal være fornuftig er tydeligvis ikke så nøye...

Session er trygt ja.

Du kan lage static variabler i ASP.Net også, men husk at "applikasjonen" din vil være delt mellom alle brukerene, så i dette tilfellet vil det ikke være hensiktsmessig.

Et lite tips; ALDRI bruk "Session" i koden din.

Dvs; Koden din == på enkelt sider.

Lag heller en "wrapper" klasse, f.eks. Sikkerhet;

internal class Security
{
 private Security() // Så kan ikke klasse opprettes andre steder
 {
 }

 // TODO : Add errorchecking/etc...
 internal static int UserID
 {
get
{
	return HttpContext.Current.Session["UserID"];
}
set
{
	HttpContext.Current.Session["UserID"] = value;
}
 }

 internal static int Email
 {
get
{
	return HttpContext.Current.Session["Email"];
}
set
{
	HttpContext.Current.Session["Email"] = value;
}
 }
}

Dermed kan du bruke Security.UserID / Security.Email overalt i koden din. Dermed unngår du at du skriver Session["SkriveFeilInniHer"] i koden din. Denne typen feil er ofte veldig vanskelige å finne ut av å debugge. Dessuten blir session variablene dine type-safe, og du får mindre kode...

btw; Det kan være en god vane å bruke public/internal/private ordentlig fra begynelsen av. Det gjør det utrolig mye enklere når du evt. skal Obfuscate prosjektet ditt senere.