I am a Senior Applications Programmer / Analyst with years of experience developing enterprise solutions using the Microsoft technology stack including C#, VB.NET, ASP.NET, AJAX, IIS and SQL Server.
I specialize in Web application development with a focus on building secure systems, integrating applications, and designing robust database structures.
First off let me start by saying that if possible it is best to avoid using cursors since they do have their drawbacks (for starters, they suffer performance issues).
However in my opinion, there are times where cursors are very useful. There seems to be an ongoing witch hunt to vilify cursors that I do not completely agree with. Just because something can be used incorrectly does not mean that you should not know how to use it, and there are scenarios where they can be useful and/or unavoidable. Basically, I am saying to use the right tool for the right job.
I was looking into updating a stored procedure that contained a cursor and needed to make the procedure perform differently based on the parameters passed in to it. To accomplish this I set out to adjust the query conditionally in a variable and run the cursor based on the dynamically created statement. Below is example code of how I assigned the SQL to a variable and then executed the cursor:
DECLARE @MainQuery VARCHAR (8000)
If @Conditional = 90
SET @MainQuery = 'DECLARE Qry CURSOR FOR SELECT First,Last FROM Address'
EXECUTE(@MainQuery)
OPEN Qry
Notice in the example that to execute the dynamically created SELECT statement the cursor constructor had to be included with the statement. Once that was done the statement could be executed through a standard EXECUTE statement.
The above method works like a charm and let’s me dynamically construct SELECT statements for a cursor.
Often when building a Web site there is a need to log the HTML of the page that is displayed to the user. This, for example, can be useful for history logging or emailing a copy of the form.
Since I frequently use .NET Webforms it is actually relatively easy to obtain the rendered HTML and store it for future use. Surprisingly there is relatively little information online about how to do this.
How is this done? The key is the page’s Render event. I add a method that overrides the page’s Render event and records the stream as it is sent to the browser. Once the page has been streamed and recorded the result can be saved to the database or stored in the session as you see fit.
Below I will give an example in VB.NET, but the principal is the same in C#:
Protected Overrides Sub Render(ByVal writer As System.Web.UI.HtmlTextWriter)
Dim sb As StringBuilder = New StringBuilder()
Dim sw As StringWriter = New StringWriter(sb)
Dim htw As HtmlTextWriter = New HtmlTextWriter(sw)
MyBase.Render(htw)
Dim thisPage As String = sb.ToString()
writer.Write(thisPage)
Session("abc") = thisPage
End Sub
I sometimes find the need to dynamically enable or disable form elements especially since I often use ASP.NET webforms. For this purpose I find that the default HTML attributes are not sufficient.
Specifically, the HTML DISABLED and READONLY element attributes do not work as one would want a disabled form field to actually work. In my opinion if a field is disabled it should not be editable, but it should post back when the form is submitted.
So just to sum up the problem: if you write a Web form with code that receives and handles the form data when it is posted, then you are looking for certain form fields to be sent to you.
To disable a field from being edited by the user you can choose one of two methods:
1) You can tag it with the DISABLED attribute. This sounds more promising than it actually is. The side effect of this attribute is that the form field is just never sent with the post, which can cause a lot of headache with code especially if you are dynamically disabling/enabling fields per user input.
2) You can tag it with the READONLY attribute. This attribute is also a big letdown. If you choose to tag a form field with the READONLY attribute then it will be sent with the post (which is good), but the field is fully editable by the user (very not so good)!
In my opinion both the DISABLED and READONLY tags end up being pretty useless so I am happy to report that a third option exists.
In my day-to-day coding I resort to JavaScript to disable form fields so that they behave the way I think disabled fields should. Specifically I want to ensure they are not editable, are sent with the form post, and appear grayed out to the user.
To do this with text boxes I add the JavaScript event onClick and set the action to this.blur(); (ie: onClick=’this.blur();’). Then I simply set the CSS background-color to #CCCCCC (ie: style=”background-color:#CCCCCC”) and I have a nicely functioning form field.
To similarly disable select lists I also add some JavaScript and CSS. Specifically I add the JavaScript event onMouseDown and set the action to this.blur(); (ie: onMouseDown=’this.blur();’). Then just like with the text boxes I set the set the CSS background-color to #CCCCCC and voila the select list is also nicely disabled! (Please note: the list will still show the drop down options when clicked, but the use will not be able to select or change the options)
Checkboxes require a slightly different approach, but not significantly so. To disable a checkbox I simply use the JavaScript onClick event and set the action to return false. In practice the code looks like this: onClick=”return false;”. This works quite nicely to disable the checkbox, but when it comes to the CSS one cannot actually set the checkbox to appear inactive. So what I end up doing is to set the background-color to the standard gray #CCCCCC, which makes the space surrounding the checkbox gray. This tends to be a good enough indication to most users that the checkbox cannot be edited.
I hope this has been helpful information. Often I will find myself under the gun trying to deliver for a tight deadline, and the last thing I want to be worrying about is how to properly disable form elements!
Justin Cooney 