Du kan måske erstatte /*Put visitortime i txtClientOffset*/ med document.getElementById("txtClientOffset").value=visitortime; MEN du kan først gøre det, når feltet findes, og det gør det først senere. Du bør derfor ændre til
<script language="JavaScript" type="text/javascript"> function aksdh() { var visitortime = new Date(); document.getElementById("txtClientOffset").value=visitortime; } </script>
"En stor skam" ... hehe :) Jo da, det er pænere på din måde Chris. Og så vil man samtidig kunne gøre det således at man nemt kan have flere onload-handlere i forskellige stumper javascript.
Hehe - måske, men den har nu sine fordele ... watch ;o)
Chris >> Nu ved jeg fra tidligere tråde, du er interesseret i at lære - og i øvrigt har bakset med this i forskellige scopes - så her følger lige en lille diskusion af ovenstående:
Ofte ses denne konstruktion anvendt: else if (typeof oObj["on"+sType]=="function") { var fnTmp = oObj["on"+sType]; oObj["on"+sType] = function() { fnTmp(); fn(); }; }
- men derved sendes evt. argumenter ikke med. Det betyder bl.a, at handler funktionen ikke modtager event objektet i Firefox o.a.
"Det betyder bl.a, at handler funktionen ikke modtager event objektet i Firefox o.a." >> Nu har Firefox vist i hele sin levetid understøttet addEventListener - men så i ældre browsere, der ikke understøtter DOM-metoden =)
Erik >> Nej, men netop i forbindelse med dit eget argument "at man nemt kan have flere onload-handlere i forskellige stumper javascript." gør funktionen det endnu lettere =)
I øvrigt scoper IE og FF forskelligt, så funktionen bør se sådan ud:
function setEvent(oObj, sType, fn) { if (oObj.addEventListener) oObj.addEventListener(sType, fn, false); else if (oObj.attachEvent) oObj.attachEvent("on"+sType, function(){fn.apply(oObj)}); else if (typeof oObj["on"+sType]=="function") { var fnTmp = oObj["on"+sType]; oObj["on"+sType] = function() { fnTmp.apply(oObj, arguments); fn.apply(oObj, arguments); }; } else oObj["on"+sType] = fn; }
Jeg siger tak for de mange gode input - også de lidt langhårede. Jeg endte med at implementere chrisbuchholz løsning, fordi det er langt lettere når man bruger master-pages i asp.net.
Ah - det er jo bade skide smart, Ole! Det sætter jeg sku pris på!:D Og fordi jeg ved at du vil trække på smilebåndet af dette, så fyrer jeg den her af:
Faktisk, så bør setEvent(window, "load", foo); være (function() { setEvent(window, "load", foo); })(); da man aldrig bør fyrer ting af i det globale scope. De skal adopteres dertil, hvis de skal være globale.
Erik >> En bakterie fra outer space er blot en ven, du endnu ikke har mødt. Klap du bare en spand Gevalia på ildstedet! :) Og hvem ved, hvilke underværker sådan en lille fyr kan gøre for en flakon af det hvide, hvis den drikker sig lystig med en gærsvamp med fælles afkom til følge? ;o)
Chris >> Jeg tror nu, du har misforstået den i webkredse pågående diskusion om "forurening af JS' globale scope" en lille smule. Der er ikke noget vundet ved dén konstruktion.
Man kan derimod f.eks. pakke variabler, der bruges af visse funktioner ind i en closure, så de ikke roder rundt i det globale scope - hvilket nu om stunder ofte anvendes i forbindelse med JS-frameworks. Her er fooBar det eneste footprint, der sættes i det globale scope:
(function(){ var nCount = 0; function foo(n) { return n + (++nCount); } window.fooBar = foo; })();
Variablen nCount hører sammen med funktionen foo i en closure og kan ikke 'ses' i det globale scope. fooBar i det globale scope referer så til foo - hvorved variablen bliver 'privat' for funktionen.
Nu vil jeg ikke begynde at diskute det med dig, Ole, men det _er_ mere case-sikkert og leak-hegnet at pakke det ind i funktioner, og så virker det også mere overskueligt når man kigger på det -> det synes jeg ihvertfald.
Jeg ville nok være lidt mere forsigtig med påstandende. Jeg er ikke sikker på, hvad du mener med 'case-sikkert' eller 'leak-hegnet' - men jeg har mine anelser ;o)
Closures har altid været en pest i IE, hvor de i forbindelse med circular references altid har været herostratisk berømt for at skabe i oceaner af alvorlige memory-leaks! Dog har MS fået bugt med de fleste af disse fejl, men netop 'closure' er et begreb, der generelt er tæt og ubehageligt associeret med begrebet 'memory-leaking'.
Jeg er helt overbevist om, der er noget, du har misforstået =)
Så er det da ihvertfald godt, at du kan oplyse mig om det, Ole. Ydermere synes jeg at du bør tage og spare lidt på tiden du bruger på eksperten, og bruge mere tid på at få gjort den nye version af dengodekode.dk færdig, så din kunnen faktisk kan spredes og komme ud til mere end de 2-3 stykker der læser i hver tråd.
Det er ikke helt den samme tid, jeg bruger på de to. Eksperten-kommentarer kan jeg stoppe ind mellem arbejde - og de bliver ofte brugt som et lille 'friminut'. Det andet er et projekt, der kræver god, sammenhængende tid =)
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
