Toon posts:

[javascript] "Vorige"-event afvangen?

Pagina: 1
Acties:

Verwijderd

Topicstarter
Ik ben bezig met een applicatie voor de Pocket PC (PDA) (javascript menu's, waaronder stack) waarbij ik wil dat de knop "vorige" een event triggert. Kan dat? De javascript aan de clientside blijft namelijk gelijk, en in mijn stack is dit vervelend. Ik houd namelijk zelf een geschiedenis van useracties bij. Als op "vorige" wordt gedrukt moet die stack dus ook gedecrementeerd worden.

Ik heb eerst geprobeerd de "vorige" knop te disablen, daarna om het history-object na elke page-request te clearen. Lukt ook niet.

Weet iemand of een "vorige"-press een event triggert?


Thx

  • InZane
  • Registratie: Oktober 2000
  • Laatst online: 06:59
Gedecrementeerd? :?

Ik begrijp wat je bedoelt, maar toch...

  • Genoil
  • Registratie: Maart 2000
  • Laatst online: 12-11-2023
ja ik geloof dat ik em ook vat. ik heb ook wel eens met wat getruuc (iets vaags met PHP, JS en sessies) geprobeerd het klikken op de "back"- button af te vangen. bleek uiteindelijk geen succes. ik kan wel ff gaan graven of ik het ding nog ergens kan vinden, maar erg bruikbaar bleek het ding niet.

tegenwoordig doe ik het anders: ik zorg dat m'n javascript-applicatie maar 1 normale request doet, namelijk de index.html opvragen. de rest van de data haal ik binnen mbv ActiveX/MSXML en m'n page updates mbv DOM/innerHTML. Zo bouw ik nooit een history op en blijft de back-button altijd "grijs" (niet klikbaar).

overigens doe ik dit nu voor een browser-based applicatie die fullscreen draait, en heb ik m'n eigen history en forward/back knoppen. voor een normale website die ook op andere platforms dan MSIE6 moet draaien zou ik dit soort grappen nooit weer uithalen.

Verwijderd

Genoil schreef op 28 april 2004 @ 13:46:
ja ik geloof dat ik em ook vat. ik heb ook wel eens met wat getruuc (iets vaags met PHP, JS en sessies) geprobeerd het klikken op de "back"- button af te vangen. bleek uiteindelijk geen succes. ik kan wel ff gaan graven of ik het ding nog ergens kan vinden, maar erg bruikbaar bleek het ding niet.

tegenwoordig doe ik het anders: ik zorg dat m'n javascript-applicatie maar 1 normale request doet, namelijk de index.html opvragen. de rest van de data haal ik binnen mbv ActiveX/MSXML en m'n page updates mbv DOM/innerHTML. Zo bouw ik nooit een history op en blijft de back-button altijd "grijs" (niet klikbaar).

overigens doe ik dit nu voor een browser-based applicatie die fullscreen draait, en heb ik m'n eigen history en forward/back knoppen. voor een normale website die ook op andere platforms dan MSIE6 moet draaien zou ik dit soort grappen nooit weer uithalen.
Je kunt dat bij relatief kleine apps nog wel doen, maar bij grotere applicaties krijg je al snel dat de boel traag wordt omdat geheugen niet meer wordt vrijgemaakt ondanks dat je al je cyclic references opruimt :)

  • Genoil
  • Registratie: Maart 2000
  • Laatst online: 12-11-2023
Verwijderd schreef op 28 april 2004 @ 14:23:
[...]


Je kunt dat bij relatief kleine apps nog wel doen, maar bij grotere applicaties krijg je al snel dat de boel traag wordt omdat geheugen niet meer wordt vrijgemaakt ondanks dat je al je cyclic references opruimt :)
@TS: "Dit topic is vanaf heden gekaapt!" 8)

ja ik ben ivm dit probleem al op zoek geweest naar topics van jou omdat ik me herinnerde dat jij er het een en ander aan tests mee gedaan had. we hebben hier als een dolle zitten klikken om er maar wat geheugengebruik bij te krijgen maar het geheugengebruik lijkt gewoon stabiel te blijven. Misschien omdat we het leeuwedeel met grote brokken oTargetElement.innerHTML=cXSLTProcessor.output doen? Nouja tis ook niet zo'n bijzonder grote app qua hoeveelheden HTML. Is het trouwens zo dat het geheugen sowieso weer vrijgemaakt wordt na een browserrefresh?

Verwijderd

Genoil schreef op 28 april 2004 @ 14:38:
[...]


@TS: "Dit topic is vanaf heden gekaapt!" 8)

ja ik ben ivm dit probleem al op zoek geweest naar topics van jou omdat ik me herinnerde dat jij er het een en ander aan tests mee gedaan had. we hebben hier als een dolle zitten klikken om er maar wat geheugengebruik bij te krijgen maar het geheugengebruik lijkt gewoon stabiel te blijven. Misschien omdat we het leeuwedeel met grote brokken oTargetElement.innerHTML=cXSLTProcessor.output doen? Nouja tis ook niet zo'n bijzonder grote app qua hoeveelheden HTML. Is het trouwens zo dat het geheugen sowieso weer vrijgemaakt wordt na een browserrefresh?
Nee, dat hangt dus af van je cyclic references. De garbage collector van de browser kan niet het geheugen vrijmaken indien deze nog bestaan, zelfde geldt voor objects in de browser.

Je kunt wel handmatig de garbagecollector aanroepen, en dit is vooral handig in MSIE voornamelijk op de onunload function, aangezien de nieuwere versies Mozilla/Firefox beter omgaan met cyclic references. De oudere versies hadden identieke problemen met geheugen gebruik.

Het is dus taak al je references de nek om te draaien vanuit het diepste niveau naar boven, alle eventhandlers de nek om te draaien, en gebruik van anonymous functions zoveel mogelijk te voorkomrn.

Overigens heeft de techniek die je gebruikt een benaming, nl. Single Paged Interfaces :) Ik gebruik het zelf voornamelijk voor bijvoorbeeld grids, waar je allee data opnieuw wilt inladen. Ik doe dit zelf dmv een zelf geschreven RPC :)

[ Voor 9% gewijzigd door Verwijderd op 28-04-2004 15:10 ]


  • Genoil
  • Registratie: Maart 2000
  • Laatst online: 12-11-2023
Verwijderd schreef op 28 april 2004 @ 15:08:
[...]


Nee, dat hangt dus af van je cyclic references. De garbage collector van de browser kan niet het geheugen vrijmaken indien deze nog bestaan, zelfde geldt voor objects in de browser.

Je kunt wel handmatig de garbagecollector aanroepen, en dit is vooral handig in MSIE voornamelijk op de onunload function, aangezien de nieuwere versies Mozilla/Firefox beter omgaan met cyclic references. De oudere versies hadden identieke problemen met geheugen gebruik.

Het is dus taak al je references de nek om te draaien vanuit het diepste niveau naar boven, alle eventhandlers de nek om te draaien, en gebruik van anonymous functions zoveel mogelijk te voorkomrn.

Overigens heeft de techniek die je gebruikt een benaming, nl. Single Paged Interfaces :) Ik gebruik het zelf voornamelijk voor bijvoorbeeld grids, waar je allee data opnieuw wilt inladen. Ik doe dit zelf dmv een zelf geschreven RPC :)
erm..ok, ik geloof dat ik de klok wel ergens hoor luiden, maar waar die klepel nou precies zit weet ik niet ;). klant heeft getekend voor een prototype, en als het kreng kuren gaat vertonen dan is dat eigenlijk dus alleen maar goed ;). Hebben we tenminste wat te doen voor de final release :P

maar op zich interessante materie, ik zal eens wat van die topics van jou wat beter gaan bestuderen :)

bij deze is de kaping van het topic ten einde :P
Pagina: 1