Globala, lokala variablar

3. Skicka in Areaid som en parameter i subben.

Ovan skrivet förslag borde vara det att föredra. Varför krångla till det? Om du skickar in Areaid som en parameter i sub:en, så kan du hämta dess värde utan att dimma den i sub:en, dim:ar den gör du nämligen när du skriver funktionen:

function doGrottvo([red]intAreaId[/red])
  doGrottvo = intAreaId
end function

eller

sub doGrottvo([red]intAreaId[/red])
  response.write intAreaId
end sub

Förstår du?

intAreaId inom paranteserna är din 'dim'.

Tyckte också att det vore smidigast, dock:
Om man vill använda en sub med sådana parametrar på andra sidor
så lär man ju skapa variablarna på alla sidor som subben hämtas på.
(om man inte gör en include-fil då)
Kommentar?

Jag tror inte riktigt att jag förstår din tankegång, men det namn som du döper variabeln till i funktions-raden har inget med att göra vad variabeln heter som du använder som parameter. Alltså; om du skickar variabeln intUserId som parameter till en sub, så spelar det ingen roll om variabeln 'dim:as' som strTjosan i sub:en. Om det var så du menade?

Funktionen ligger lämpligast i en include fil, ja.

Dessutom behöver du inte ha just en variabel som parameter i anropet, du kan göra såhär med:

'sub
sub doSomething([red]strVal[/red])
   'gör nåt
end sub

'HTML eller nåt

'anrop
call doSomething([red]recSet("kolumn")[/red])

Då kastar du in ett recordset direkt i anropet.

Redigerat) Fel kodat, så in i berget.

Jag menade nog ungefär så här:
Om jag har denna sub

Sub Area(intAreaid)
nånting händer...
End Sub

Och intAreaid ska hämtas från en querystring eller en form så lär jag ju skapa på varje sida en variabel typ:

Dim Areaid
Areaid = Request.Querystring("Areaid")
If Len(Areaid) = 0 Then Areaid = Request.Form("Areaid")
Call Area(Areaid)

Men flyttar man in variabeln i subben slipper man det problemet:

Sub Area()
Dim Areaid
Areaid = Request.Querystring("Areaid")
If Len(Areaid) = 0 Then Areaid = Request.Form("Areaid")
nånting händer...
End Sub

Nja.. jag skulle nog hellre göra såhär:

sub doSomething(AreaId)
   if Len(AreaId) = 0 then
      'skriv nåt eller gör ingenting
      'response.write "Felaktig parameter."
   else
      response.write AreaId
   end if
end sub

intVal = 2313
call doSomething([red]intVal2[/red])

Så det är alltså "ej korrekt programmeringsetik" att skriva

Sub Area()
Dim Areaid
Areaid = Request.Querystring("Areaid")
If Len(Areaid) = 0 Then Areaid = Request.Form("Areaid")
If Areaid = bla...
End Sub

Call Area()

Det kan ju vara så att man har 5, 10 värden som subben ska använda och då får man skriva samma kod många ggr. om subben ska användas på ett flertal sidor.
Ex.
sida 1

<--include med subbar -->
Dim Areaid, Areaid2, Areaid3
Areaid = bla...
Areaid2 = bla...
Areaid3 = bla...
Call Area(Areaid,Areaid2,Areaid3)

Alla andra sidor lär då också ha samma kod.

(förmodligen krånglar jag till det i onödan, men jag vill så gärna göra "rätt")

Jag förstår hur du tänker. Vet du vad det tråkiga är med det? Du kan inte bestämma hur många parametrar du skall skicka till din sub/funktion i anropet. Detta måste bestämmas i funktionens design. Och då falerar ditt tänkande med inkludefilen ändå.

Skickar du fem parametrar till funktionen och har 'dim:at' tre, kommer du få ett runtime-error.

Jahapp, jag tror att man får ta och bygga ett eget språk då så man får som man vill!

Tyvärr kan vi inte bestämma över hur det fungerar.

I vilket fall som helst; meningen med funktioner och subrutiner är att kunna köra en bit inkapslad kod som gärna upprepas på olika ställen och tidpunkter över hela sidan/applikationen. Istället för att "spagetti-koda" in själva logiken mitt i ASP- och HTML-gröten, så kan man enkelt få bort tung, avancerad eller upprepande logik ur presentationslagret och lägga det i ett eget lager. Dessutom, om denna logik (i din funktion) behöver ändras, så slipper du göra det på alla de sidor där den anropas; du gör det enbart i funktionens design.

Detta kan väl egentligen ses som ett steg mot den sk. three-tier-metoden, att separera logik, presentation och datalager.