by Mark Trescowthick - GUI Computing
I've been battling my way through ASP development now for four months or more… and along the way had the typical hassles (and, thankfully, solutions) we all experience in a new environment. This article is an attempt to document a few of these in the hope that you won't have to do the puzzling out I've done.
Now, what I was going to do was create an example application which illustrates a few of these… but each snippet stands on its own in many ways. And besides, that would involve hard work!
One note here... these bits and pieces apply to ASP 1.1 and IIS 3. We're promised (and are getting) much expanded functionality in IIS 4.
So, without further ado, Miscellany…
"I need to specify a Frame Target, and can't see a way to do so." You're correct. There isn't one - at least, not directly. My article last month gives you a couple of sneaky ways around this silly limitation, but other than that, you're on your own!
"What does this Buffers Already Written error message mean?" You can only redirect (or do any other response-based code) before you finish the header (i.e. all that stuff before the <html> tag) output. There are two ways around this.
The most obvious is to do any redirect before that tag - which is nearly always possible. The second is to set response.buffer to true. This means that no output is actually done, and you can put your response.redirect wherever you like. Of course, you need to remember to set response.buffer to false before you finish!
"Only some of my querystring variables are getting through. Why?" Most normally, you can bet this is because there's a space (or some other abominable character) somewhere. For example :
response.redirect "myasp.asp?Name=MarkTrescowthick"will result in request.querystring("Name") returning "MarkTrescowthick" whereas
response.redirect "myasp.asp?Name=Mark Trescowthick"will result in it returning "Mark"… and worse, all subsequent arguments returning nothing at all!
The solution? Server.URLEncode the string first :
myName = Server.URLEncode("Mark Trescowthick") Response.redirect "myasp.asp?Name=" & myName
If you need to unpick the URLEncoded string, Server.HTMLEncode normally does the trick.
Buttons and Graphics
It's pretty common practice among many developers to get things running first using those horrible grey buttons, then want to change later on to something a trifle more aesthetic. This can cause pain, as can relying on the Value of a button - which turns out to be its caption, and which is almost certainly going to change (users being what they are).
For this reason, I take the following approach to all navigational code :
if request.form("cmdAnswer1.x") <> "" or request.form("cmdAnswer1") <> "" then '… do something end if if request.form("cmdAnswer2.x") <> "" or request.form("cmdAnswer2") <> "" then '… do something end if
You'll note that this method relies on the fact request.form will only return a value for a button (or graphic) if it's been clicked. Also note that I check for the .x value (which will be present if a graphic has been used) as well as the value (which is present for a button). This method completely avoids relying on caption text or any other assumptions. I actually have a tiny function to do this generically, which avoids a good deal of coding :
Function IsAction (ActionName) IsAction = False If request.form(ActionName & ".x") <> "" or request.form(ActionName) <> "" then IsAction = True End If End Function
The Session Object
"Help, my Session variables disappeared!" Actually, that's probably what they were "supposed" to do (ahem!). If you change virtual directory or server, ASP allocates a new Session ID. Which sort of makes sense… and sort of doesn't. The net effect is that, for session variables to be maintained, you must stay within a directory (and its subdirectories).
If you really need to move (and I've had that problem), move your session variables over in a querystring, and then re-establish them.
"How do I emulate the Back button on the Browser?" Make use of the cannily misspelled HTTP_REFERER… as in Request.ServerVariables("HTTP_REFERER"). This will give you the URL of the referring page. From then on, it's easy.
"But I don't want them to be able to go back - the database has changed!". This is a common problem… browser caching is very much a two-edged sword. Setting Response.Expires to 0 in the page you don't want to be cached will work.
"The longer my application runs, the more memory the server seems to consume." Well, here we're in the land of ASP patches and other such nasties… check microsoft.com for the latest patch. There's a Knowledgebase article devoted to this very subject.
But before you do so, make sure that you're doing your garbage collection correctly… for ASP certainly doesn't!
You would assume, for instance, that after a page was processed, any objects in that scope (e.g. recordsets) would be disposed of unceremoniously. Not so. You need to explicitly set each object to Nothing to ensure that the memory used is freed up again.
I have a small CloseRecordSet function which handles this for me :
Function CloseRecordSet (ByRef rsName) rsName.close set rsName = nothing CloseRecordSet = True End Function
"I want to send mail from an ASP." Not without an addon, I'm afraid. That's the bad news... the good news is that Steve Genusa's ASP Developers page has a great (and cheap) addon that does the job admirably. In fact, his page is a must-visit for ASP developers anyway.
The best resources for solid information I've found are Steve Genusa's page, 15 Seconds Magazine and the MS Newsgroups.
I'm sure there are a million and one other traps for young players that, for one reason or another, I haven't managed to fall into just yet… and probably some other great sources of info out there somewhere. Any contributions would be most welcome!