mandag, august 20, 2007

Betingelser(If, Else, Switch og case)

Om Betingelser

At sætte betingelser op i sin kode er noget som man kommer til at bruge næsten hele tiden. F.eks. hvis det er mandag skal man bruge den baggrund, ellers skal man bruge en standard baggrund. Det kan også være man vil teste på, om den bruger der er logget ind på dit website er administrator, og hvis han er, skal han selvfølgelig videre ind på en administrator side.

If/else betingelsen

Betingelser er en af de lettere ting at lære i C#, da de er lette at forstå. Hvis vi starter med en simpel betingelse.

if (Brugerrettighed == "Administrator")
{
//kode der sender ham videre til en administrator side.
}
else
{
//kode der sender ham ind på en almindelig brugerside
}

Som man kan se er det faktisk ligetil at forstå. If betyder Hvis og det der står her er, Hvis brugeren status er administrator, skal han ind på administratorsiden. Såre simpelt.

Man kan mere eller mindre sætte alle betingelser op som man lyster. Hvis nu der skal være flere valgmuligheder kan man imellem if og else skrive Elseif. På den måde kan man sætte ligeså mange muligheder op man ville.

Switch/Case betingelsen

Selvom ElseIf er god at have, er den noget upraktisk. Forestil dig at du skal teste på 10 betingelser. Det ville kræve ikke så lidt uoverkuelig kode, så når man har mere end 1 betingelse at teste efter, bruger man en anden metode som hedder Switch/case. Måden den fungerer på er meget lig If og Else, men med en væsentlig forskel. Den kræver mindre kode. Her er et eks:

Switch (Brugerstatus)
{
case administrator
//kode der sender til adminsiden
break;
case VipBruger
//kode der sender til Vip bruger siden
Break;
Case AlmBruger
//Kode der sender til den almindelige brugerside
Break;
default:
//kode der udføres hvis ingen af de andre betingelser er sande.
Break;
}

Læg mærke til vi bruger keywordet Break for at fortælle, at nu har vi fundet og udført det stykke kode der skal bruges, og så vil vi gerne videre med vores kode. Så vidt jeg husker, får man en kompile fejl hvis man udelukker break, men jeg er ikke sikker på man ikke kan bruge Continue til at fortsætte med at teste efter de andre muligheder bagefter.

Afslutning

Som man kan se, er If strukturen den nemmeste at bruge hvis man kun har en betingelse. Den har også flere muligheder, da betingelsen man tester efter, kan være af næsten hvilken som helst form. Switch er mere brugt hvis man tester efter en masse simple ting, som f.eks. et navn eller et tal, da det giver et meget bedre overblik i din kode. Man kan dog bruge begge muligheder som man har lyst til, og jeg mener ikke det giver nogen væsentlig hastighedsforskel.

God kodelyst

søndag, august 19, 2007

Løkker i .Net

Om løkker

Løkker er, ligesom næsten alt andet jeg har skrevet om indtil nu, en meget væsentlig del af .Net. Det er faktisk en meget væsentlig del af næsten alle programmeringssprog.

Forestil dig du har en liste med personer. Du vil gerne hive personen ud der hedder Johnny. Istedet for at bruge kode på hver enkelt person du hiver ud, kan du smide det ind i en løkke. Så løber løkken igennem alle dine personer i listen indtil den støder på en person der hedder Johnny, som den så hiver ud. Hele koden til at hive personen ud med, skal du kun skrive en gang. Og udenom den kode skriver du din løkkekode, som så kører den samme stump kode igennem det antal gange du beder den om. F.eks. det antal gange som der er personer i din liste.

For løkken

Der findes mange slags løkker i C#. men en af de mest gænse er denne her:

For (Type Tællernavn=startnummer; tællernavn <= slutnummer; starnummer+=antal trin. Lyder det indviklet? Lad os prøve at forklare hvad der menes. Type = den type tæller der skal tælles på. f.eks. Int. Tællernavn = Det du vil kalde din tæller. Det mest normalle for int i en løkke er "i" startnummer = Det sted du vil starte. som regel starter man med at tælle fra 1. Slutnummer = Det nummer vi skal stoppe med at tælle fra. f.eks. 10(løber igennem 10 gange). Antal Trin = Det nummer som der skal forøges med for hver gang man tæller. Typisk 1. Så hvis vi skriver det som koden skal være, kommer det til at se sådan ud:

For (int i=1; i<=10; i++)
{
//kode der skal gentages i løkken
}


Hvis du vil bruge din tæller inde i løkken kan du kalde den med det navn du har givet den. f.eks. "i" som vi har brugt i det tilfælde her. Hvis du bad den om at skrive i ud på skærmen i din løkke vil den skrive numrende fra 1-10. i++ fortæller bare at den skal forøge i med 1.

Hvis man skal gøre det rigtigt advanceret så kan man inde i løkken lave en ny løkke så man hver gang man løber løkken igennem, kører en ny løkke et antal gange.

Break og Continue

Hvis man ønsker at hoppe ud af sin løkke, f.eks. hvis man har fundet den person man ledte efter, kan man bruge det keyword der hedder Break. Break gør nøjagtig som den lyder, afbryder din løkke og fortsætter med koden efter løkken. Man kan også bruge det keyword der hedder "Continue" som vil hoppe ud af det gennemløb i løkken man er igang med, og fortsætte med det næste.

While

En anden måde at lave en løkke på er med While metoden. I modsætning til For løkken er While løkken ikke afhængig af at løbe igennem koden et vist antal gange. While vil kun løbe igennem koden så længe den betingelse du angiver er opfyldt. While ville passe bedre til at løbe igennem en liste med personer, da du som regel ikke ved hvor mange personer der er i listen på forhånd. Så istedet beder du While løkken om at løbe igennem så længe der er flere personer i din liste. Smart ikke.
Måden at skrive en while kode på er:

While (Personer i listen)
{
//Kode der skal gøre noget. F.eks. skrive navnene ud på skærmen
}

While løkken kan også indeholde Break og Continue.

Hurtig afslutning

Det var lige et hurtigt eksempel på de mest brugte løkker, men der findes også Do/while og foreach. Dem vil jeg ikke gå så meget i detaljer med i denne omgang.

God kodelyst

fredag, august 17, 2007

Læsevenlig fejlmeddelelse til dine brugere

De fleste af os kender problemet. Vi sidder og surfer på en interessant side eller artikel, klikker på et link for at komme til en anden artikel, og vupti. En eller anden teknisk fejlmeddelelse om at siden ikke eksisterer eller har en programeringsfejl i linie xxx.

Faktisk så sent som idag fik jeg faktisk en rigtig kedelig fejlmeddelelse på en meget brugt side, som omhandlede en kodefejl i et XML dokument. Vi som kodere ved godt hvad det betyder, men hvis nu Olga Olsen med sin 386'er kom ind på siden, ville hun bruge det meste af aftenen på at klø sig i håret og derefter surfe videre til et andet website.

For at komme over det problem kan man i C# og andre .Net sprog lave noget der hedder Exception handling eller frit oversat, undtagelseshåndtering. Det betyder i bund og grund, at istedet for at brugeren får en teknisk fejlmeddelelse, kan mman lave noget kode der gør det nemmere for kunden. Såsom at der på skærmen står: "Undskyld. der er sket en fejl og du kan ikke bruge denne side lige nu. Prøv igen senere". Du kan endda samtidig lave noget kode der sender en email til dig med fejlens detaljer, så du bliver gjort opmærksom på at det gik galt. Smartere kan det ikke blive. Så lad os se på hvordan vi kan lave det i vores kode.

Try og catch

F.eks. hvis du skal forbinde til en database, er der en mulighed for at databaseserveren er nede, så det ville specielt være et sted du ville sikre dig en brugervenlig meddelelse hvis det går galt. Det kan du gøre ved hjælp af 2 keywords. Try og Catch. F.eks. Sådan her:


Try

{

//Kode der forbinder til databasen

}

Catch

{

//kode der håndterer hvis det går galt, som f.eks. 'Console.writeline("UPS")'

}



Try betyder prøv, og indikerer at imellem tuborgklammerne kommer der noget kode du gerne vil prøve om virker. Catch betyder fang, og indikerer, at hvis skidtet ikke virker fanger vi det imellem de efterfølgende tuborgklammer{}.

Finally

Det der så sker nu, er at når brugeren har fået en fejl, så kører dit website eller program ikke videre, og det er ikke altid hensigtsmæssigt. F.eks. hvis du har åbnet forbindelsen til din database, bliver den ikke lukket hvis fejlen sker når den prøver at hente noget fra databasen og det ikke findes. Og det ville tage unødige resurcer og hukommelse. For at afhjælpe det problem kan man efter Catch's tuborgklammer bruge det keyword der hedder Finally.
F.eks. sådan her:


Try {//kode der åbner databasen og henter noget}
Catch{//Kode der giver en fejlmeddelelse hvis noget går galt}
Finally{//Kode der skal afvikles efter at fejlmeddelelsen er kommet.
som at lukke databasen og viderestille brugeren til en anden webside}


Håndtere specifikke fejl hver for sig

De fleste vil allerede nu kunne se det smarte i undtagelseshåndtering. Men det slutter ikke her. Du kan rent faktisk lave en overloaded fejlhåndtering, så du kan lave en fejlmeddelelse alt efter hvad der rent faktisk går galt. .Net har nogle indbyggede måder at finde ud af hvad for en fejl der er sket, og det kan man rent faktisk bygge ind i sin catch på følgende måde:


Catch (FileNotFoundException)
{//kode der skal udføres hvis filen ikke er fundet}


Alle fejlhåndteringsmeddelelser kan findes under det namespace der hedder System.Exception
Det kan altid betale sig at skrive den fejl man tror man vil møde hyppigst som den første fejl den skal lede efter. På den måde sparer man regnekraft på at den skal igennem de første 40 muligheder før den finder den rigtige hver gang.

Få fejlens detaljer skrevet ud sammen med din fejlside

Hvis man nu vil have detaljer om fejlen med i sine fejlmeddelelser, er der også en måde man kan håndtere det. Da System.Exception er en klasse kan man oprette en ny instans af klassen i sin catch. f.eks sådan her

Catch (exception e)

Nu kan du kalde en række detaljer ved at skrive e.detaljekeyword. f.eks e.message som vil skrive på engelsk hvad for en fejl der er opstået. Disse specifikke meddelelser kan bl.a. bruges hvis man laver noget kode der sender en email til administratoren af et website når der sker fejl. Så kan man i emailen vedhæfte detaljer om fejlen, så administratoren eller webmasteren ved hvad han skal kigge efter når han skal rette fejlen. Smart ikke :-D

Lav dine egne undtagelser

Hvis i tror det er det hele, så tager i fejl. Det er jo smart nok at .Net har indbygget undtagelser, men hvad nu hvis du vil lave din egen undtagelse?
Til dette kan man benytte et keyword der hedder Throw, eller frit oversat "Kast".
Et muligt eksempel kunne være hvis man beder brugeren om at indtaste en dato, men brugeren vælger at indtaste "Jeg elsker barbiedukker". Så kan man gøre det således:

Catch
{ throw new Exception("Du har ikke indtastet en dato");}

Det smarte ved at gøre det på den måde er, at .net behandler det som en hvilken som helst anden undtagelse, og derfor kan man håndtere dem, som beskrevet længere oppe, som en hvilken som helst anden undtagelse. .Net genereret eller ej.

Afslutning

Jeg håber at det har været en tilstrækkelig forklaring på undtagelseshåndtering, men hvis i synes der mangler noget eller hvis jeg har lavet fejl eller forstået det forkert, så smid en kommentar til mig, og så retter jeg det til.

God kodelyst

onsdag, august 15, 2007

mandag, august 13, 2007

Angående undervisningen på AATS.

Jeg har lige læst "Kamelens" indlæg angående læreundervisning på ålborg tekniske skole, og må faktisk give ham ret i næsten alle ting. Dog synes jeg faktisk at jeg lærer noget stadigvæk, men den gensidige respekt mellem lærer og elev er slet ikke den samme som da jeg gik på hovedforløbet sidst.

Spørgsmålet er, om hvad vi kan gøre for at det bliver bedre. For selvom jeg synes at det meste af skylden ligger ved læreren, synes jeg heller ikke vi gør det nemt selv. Bl.a. er jeg meget god selv til at smide paraderne oppe så snart der er det mindste, istedet for at tage en normal samtale, og det tror jeg vi allesammen gør. Så når der bliver sagt/gjort noget vi synes er uretfærdigt og forkert, så bliver vi sure og mobsede og brokker os. Vi burde måske istedet tage en ordentlig samtale med den/de pågældende ang. hvad vi synes er forkert, og så lad os se om vi ikke kan få styr på det. Jeg ville selv som lærer bare blive endnu mere sur og tvær hvis jeg bare fik brok og brok istedet for en stille og rolig snak om hvad der var utilfredsstillende og hvad der kunne gøres for at rette det. Og jeg tror faktisk at hvis vi kan stille et forslag til hvad der kan gøres for at rette det, så vil den/de pågældende lærere også tage det til revurdering eller på prøve en periode, hvis ellers forslaget er retfærdigt.

Kunne godt tænke, at i andre måske kom med jeres mening. Også lærene :-)

søndag, august 12, 2007

Klasser, hvordan man laver og bruger dem

I en af de forrige blogs fortalte jeg lidt om hvorfor man bruger klasser, hvad det gode er ved dem, og en smule om hvordan man laver dem. I denne blog vil jeg gå lidt mere i dybden med det og prøve at oprette en bruger-klasse med nogle brugeregenskaber såsom brugernavn, rigtig navn, alder, by og brugerbillede. og alt det vil jeg så lave en metode der kan formatere til html, så vi kan se det i en pæn udgave på skærmen bagefter.

Som i sikkert kan huske fra tidligere, så har vi selve klassefilen som skal ligge i App_Code folderen. Start med at oprette sådan en klasse(class) og kald den Webuser.cs.
Læg mærke til at Visual Studio/Visual Webdeveloper selv laver en skuffe der hedder App_Code og ligger Webuser.cs i den hvis i svarer ja til det.

Den bedste måde at se på .cs filen, er som en arbejdstegning. webuser.cs kommer ikke til at indeholde oplysninger om selve brugerne, men oplysninger om, hvad vi skal vide om brugeren. Det vil sige at vores webuser.cs i dette tilfælde kommer til at indeholde nogle egenskaber der hedder "username", "Age" og en metode der hedder "HtmlOutput()" Hvis der bliver mulighed for det, vil jeg se om jeg ikke kan smide en event eller 2 i min Users.cs også, men da jeg ikke selv føler jeg har styr på dem endnu, så tør jeg ikke love noget.

Lad os komme tilbage til Webuser.CS som i nu har oprettet. Der burde nu stå følgende:





public class Webuser
{
public Webuser()
{
//
// TODO: Add constructor logic here
//
}
}



Dette i sig selv gør ikke det store så lad os prøve at smide lidt oplysninger i den. Lad os smide brugernavn, alder og by i den. Det gør vi ved at lave 3 strings på følgende måde:





public class Webser
{
private string Username;
private string Age;
private string City; private string Userpicture;
}



Læg mærke til jeg har smidt "private" foran mine strings.. Dette betyder at jeg kun kan tilgå mine strings fra selve klassen. hvordan vi så bruger dem kommer jeg til for det giver mig senere mulighed for at lave noget kode i klassen der sikrer at det er gyldige data der står i variablerne, så der ikke ved et uheld kommer til at være en tom variabel.. så får vi bare fejl når vi kompilerer koden, eller endnu være. Brugeren af dit website får en fejl smidt i hovedet når han prøver at oprette sin egen bruger.

Nu har jeg mulighed for i min code-behind at lave en ny bruger ved at skrive:



Webuser NyBruger = new Webuser();



Det vi lige har gjort er at tage vores Arbejdstegning der hedder Webuser.cs, og ud fra den har vi nu lavet en ny bruger der hedder NyBruger. Det er en start, men vi vil også gerne kunne fortælle hvordan vores NyBruger kan få et brugernavn, alder og en by. Hvis vi havde lavet vores egenskaber public istedet for private, ville vi kunne give vores bruger brugernavn ved at skrive NyBruger.Username = "Johnny"; Men nu har vi gjort den private, så derfor kan vi ikke bare få fat i den sådan. For at kunne bruge den skal vi tilbage til vores Webuser.cs og skrive lidt mere på vores kode. Det vi skal have gjort er at lave noget der hedder "Accessors" eller "adgangsbrugerflade" hvis man kan kalde det det. Det gør vi sådan:





public class Webuser
{
private string Username;
private string Age;
private string City;
private string Userpicture;
public string username
{
get { return Username; }
set { Username = value; }
}
public string age
{
get { return Age; }
set { Age = value; }
}
public string city
{
get { return City; }
set { City = value; }
}
public string userpicture
{
get { return Userpicture; }
set { Userpicture = value; }
}
}


Det vi har gjort nu er at lave nogle adgangsmuligheder så man kan tilgå Username osv. fra vores code-behind. Læg mærke til at vores Public string er lavet med KUN små bokstaver. Dette er fordi at vi ikke må bruge samme navn som vores private string. normalt er det ikke god praksis at kalde sine variabler det samme, men i dette tilfælde er det faktisk helt lovligt og meget almindeligt. Der er også nogle, der istedet for at bruge små bokstaver bruger _Username istedet. Det er helt op til en selv hvad der er nemmest at bruge. begge ting bliver brugt til dagligt.

Hvis i kigger i jeres code-behind så har i nu adgang til at kalde de forskellige ting i jeres klasse med Webuser.Username, Webuser.City osv. men hvis nu vi skal smide en metode i til at lave noget fancy html på skærmen, så kræver det lidt mere.

Da denne blogting er så elendig så jeg ikke kan skrive htmlkode i den uden den formaterer den, så har jeg erstattet alle <>tags med [] tags. De skal selvfølgelig rettes til når man skriver den ind.

For at det ikke skal blive for uoverskueligt har jeg skåret lidt ned på starten af klassekoden, da jeg allerede har gennemgået den ovenover:



public string userpicture
{
get { return Userpicture; }
set { Userpicture = value; }
}
public string HTMLOutput()
{
string HtmlString;
HtmlString = "[h1]" + Username + "[/h1]";
HtmlString += "[h4][b]Age: [/b]" + Age + "[/h4]";
HtmlString += "[h4][b]City: " + City + "[/h4]";
HtmlString += "[img src=" + Userpicture + "]";
return HtmlString;
}
}

Det jeg har gjort her er bare at smide en simpel metode ind i min klasse som kan lave noget fancy html til skærmen, så det jeg evt kunne gøre nu er at kalde metoden fra min code-behind med "response.write(Webuser.HTMLOutput().tostring())" Så simpelt er det.



Det er så det jeg mente jeg lige ville gennemgå idag. Men jeg vil tilføje lidt mere herinde efterhånden som jeg lærer nye ting. Husk, at det her er bare sådan jeg har forstået hvordan tingene fungerer, og der kan være nogle ting som jeg måske har forstået forkert. Hvis i opdager nogle fejl, så smid en kommentar. Så kan jeg også selv blive klogere.





God kodning



fredag, august 10, 2007

Metoder: Hvad kan de bruges til og hvordan fungerer de?

En stor del af at arbejde med C# omhandler en del brug af metoder til at udføre forskellige ting.
metoder kan være lidt svære at forstå i starten, men når først man har fundet ud af hvordan de virker, kan de ikke undværes. Specielt fordi de hører til det mest basis programmering i C# og .NET i det hele taget. Jeg har taget et lille kig på nogle simple metoder og vil forsøge at forklare lidt om hvad de forskellige ord/keywords betyder og hvorfor man bruger dem.

En basis metode:

Hvis vi starter ud med at lave en basis metode, så vil jeg derefter forsøge at pille den fra hinanden og forklare delene af den.





Public Void MetodeNavn()

{

//Her skal skrives en masse kode

}






Det er er det helt basale for en metode. Public indikerer at du kan tilgå metoden udefra. Jeg kunne have brugt Private istedet hvilket vil have indikeret en privat metode som ikke kan tilgås fra f.eks. et andet dokument.

Void: betyder faktisk tomt, eller tomrum, men i dette tilfælde bruger man Void når man laver en metode der ikke smider noget data tilbage til dig når den er færdig. Hvis den nu skulle have smidt f.eks. et navn tilbage ville man have brugt String istedet.

Metodenavn: Her kan du navngive hvad du vil kalde din metode. Det mest smarte ville selvfølgelig være hvis du navngav den noget der giver mening. F.eks. "FindNameFromDB". At kalde den Kaffekop vil måske være kanon sort humor, men det sjove holder op når du har 50 metoder der hedder alt fra chokoladetærte til fjernsynsflimmer og du skal finde ud af, hvilken metode der henter navne fra databasen. så skal du sidde og nærstudere din kode hvilket nok er knapt så sjovt.

Tuborgklammerne indrammer selve den kode der er i metoden. Lad os prøve at udvide metoden en lille tand.





Public Void MetodeNavn(int nummer1, int nummer2)

{

int resultat = nummer1 + nummer2;

return resultat;

}





Her har vi udvidet metoden så den tager 2 parameter. Begge parameter er int. Jeg skal nok forklare lidt senere hvordan man sender de 2 parameter til metoden.

Inde imellem tuborgklammerne har jeg lavet en simpel beregning der ligger de 2 numre sammen og smider den i en variabel der hedder resultat. Jeg bruger derefter kommandoen "return" for at sende resultatet tilbage til det sted hvor der blev bedt om det.
Jeg kunne have forkortet det lidt og bare skrevet "return nummer1 + nummer2;"
Det havde virket ligeså fint og faktisk sparet en bid hukommelse fordi at vi sparede oprettelsen af en variabel.

Lad os nu sige vi har smidt vores fine metode ind i en klasse som f.eks. vores tidligere Is.cs(se tidligere blogpost) kan vi kalde metoden fra et hvilket som helst sted, når vores instans af variablen er oprettet med: "MitIsKlasseInstansNavn.MetodeNavn (20, 30);".

Her indikerer vi at vi vi vil have fat i den metode der hedder MetodeNavn som ligger i den klasse som vores MitIsKlasseNavn er oprettet i(Is MitIsKlasseNavn = New Is).
Samtidig med vi kalder metoden smider vi 2 parameter med. Disse parameter ryger ind som nummer1 og nummer2 i vores metode og bliver lagt sammen, så vi i sidste ende for nummeret 50 tilbage..

Så hvis vi f.eks. skriver



Int PlusBeregning = MitIsKlasseInstansNavn.MetodeNavn (20, 30);

console.writeline(PlusBeregning); //Skriver tallet 50 ud på skærmen




Metode Overloading

Den sidste ting jeg vil kigge på inden jeg slutter af er Metode Overloading.
Lad os nu sige at du har en metode til at hive et produkt ud af en database men du er ikke sikker på om brugeren vil bruge produktets ID eller produktets navn når de skal hive produktet frem. For at komme over det problem kan man bruge Metode Overloading, hvilket faktisk bare er at oprette flere metoder med det samme navn, men som tager forskellige parameter.



Public void MetodeNavn(int ProduktID)

{

//kode der henter produktet ud fra dets ID

}

Public void MetodeNavn(String ProduktNavn)

{

//Kode der henter produktet ud fra dets Navn

}




Læg mærke til at begge metoder har nøjagtig samme navn. Men hvis du kalder metoden med en string er .Net så smart at den automatisk finder den rette metode som bruger en string som parameter, og det samme er selvfølgelig gældende med int.

Husk at du ikke må lave 2 metoder som hedder det samme og tager samme antal og slags parameter, men man kan sagtens lave 2 metoder som hedder det samme, som begge tager int, men som tager forskelligt antal. F.eks. hvis den ene tager 1 parameter, og den anden tager 2.

Afslutning

Så fik vi også gennemgået lidt om metoder. Husk på, at dette er noget jeg selv lige har læst og lært og derfor kan jeg ikke helt garantere at der ikke er fejl i min kode, eller at der er noget som jeg har misforstået, men i må MEGET gerne skrive kommentarer til det og gerne rettelser til det så jeg evt, kan lære af mine fejl. Min basis mening med disse blogs er som hjælp til mig selv til at huske hvad jeg har læst og til andre som måske har brug for en anden måde at få forklaret tingene på.

Held og lykke med kodningen :-)