Het heeft even geduurd, maar we hebben een valide reden gevonden om het ASP.Net AJAX framework te implementeren in een project op het werk.
Eigenlijk was het al veel langer nodig, maar met de nodige work-arounds en eigen AJAX-methoden konden we toch nog zonder het standaard framework werken.
Ik had nu echter ook masked edit’s nodig in m’n project en om die functionaliteit nou zelf te gaan maken gaat mij iets te ver als er al zoiets bestaat.

Gisteravond heb ik eerst gekeken of het framework een beetje eenvoudig kon worden geimplementeerd in het project. Nadat ik dit enkele malen had geprobeerd werd mij duidelijk dat dit een triviale kwestie was. Wat wel vervelend is, is dat ik geen ‘upgrade’ kon doen van m’n ASP.Net website naar een ASP.Net AJAX website, dus moest er een nieuw project worden aangemaakt.
Dit heb ik dus maar gedaan en alle bestanden van het oude project hier ingeladen. Uiteraard wel met dezelfde namespace, want anders zou ik alsnog problemen krijgen met referenties en dergelijke.

Na dit gedaan te hebben kon ik de standaard AJAX onderdelen gebruiken. Op zich leuk, maar hier zit geen masked edit control in. Deze moest nog apart worden geinstalleerd door middel van de Control Toolkit. Die voor .Net 3.5 was behoorlijk snel te vinden, maar ik moest die voor .Net 2.0 hebben. Deze was 2 muisklikken verder weg.
Deze snel even installeren en toen begon het puzzelen. Eigenwijs als ik ben dacht ik dit wel spelenderwijs te kunnen installeren. Dat bleek dus niet zo te zijn.

Vandaag kwam ik tijdens de ontwikkeling van een web-applicatie iets vervelends tegen.

Momenteel ben ik bezig met een ASP.Net 2.0 applicatie en daar wordt gebruik gemaakt van een basis uit ASP.Net 1.1. Op zich geen probleem en alles werkt ook goed, echter hebben we enkele nieuwe features toegevoegd die mogelijk werden gemaakt in 2.0 van het .Net Framework. Een van die dingen zijn Masterpages.

Een enorm handige feature en het werkt ook wel leuk. Hoewel ik me er niet enorm in heb verdiept snap ik de basis wel en zie ook wel dat het handig (kan) zijn.

Met de introductie van Masterpages introduceer je ook weer nieuwe problemen in je al bestaande web-applicatie.
Een van die problemen die ik vandaag ben tegengekomen is het gebruik van de functie FindControl. Deze kun je normaliter gebruiken om een control in je pagina op te zoeken aan de hand van een ID. Dit is nog steeds het geval, echter worden de ID’s van je controls aangepast zodra ze in een masterpage staan. Je kunt dus niet meer zoeken op bijvoorbeeld het ID testLabel. Nee, hier staat nu een hele prefix voor.

Na even te hebben gezocht op internet kwam ik al snel op een oplossing voor dit probleem. Door middel van een recursieve functie te gebruiken kun je alle controls doorlopen en dan toch naar je ’eigen’ ID zoeken.

Op het werk kwamen we er gisteren achter dat wanneer je een Response.Redirect doet je een ThreadAbortException in je applicatie krijgt. Tenminste, als je de redirect doet in een try-catch blok.

Deze exception is ‘by design’ in het .Net Framework gestopt. De reden hiervoor is dat het de bedoeling is dat de huidige pagina niet door hoeft te gaan met uitvoeren en je gelijk naar de andere pagina wilt gaan.
Door middel van deze exception wordt dit bewerkstelligd.

Aangezien we dit nog niet wisten, werden er enkele reacties gespuwd over deze oplossing voor het beëindigen van een web-pagina. Onze team-leider kwam net een leuke analogie, namelijk:

Het is alsof je met een auto moet remmen en dan maar een steeksleutel in de moter gooit om te stoppen. De auto komt dan ook stil te staan.

Persoonlijk vond ik dat wel een leuk statement.
Na even te hebben gezocht op dit ‘probleem’ kwam ik op een Microsoft pagina uit. Hier staat het probleem beschreven en is er ook een oplossing beschikbaar. Eerst de https://support.microsoft.com/kb/312629.

De oplossing luidt dat je een overloaded functie moet gebruiken van de Response.Redirect, namelijk Response.Redirect(String url, bool endResponse). Door de tweede parameter op `false te zetten zul je geen exception krijgen.