Latest ASP.NET Articles from 4guysfromrolla.com

While reading through some of Jeff Atwood's old blog entries, I stumbled across this gem: The Danger of Naivete. In it, Jeff discussed the pitfalls the can befall a programmer who implements a naive algorithm and calls it a day. Consider an algorithm to randomly reorder an array. If you have a collection of items to reorder, the naive approach is to enumerate each element and swap its position with an element in some other randomly-selected position. However, such an algorithm (as we discuss in this article), does not have an even distribution of results - certain permutations are more likely than others when starting from a set point.

Jeff's blog entry caught my attention because of a past article I wrote here on 4Guys, Randomly Reordering an Array. That article, written back in 2000, showed various techniques for reordering an array in classic ASP using VBScript. And, wouldn't you know it, the first technique uses the exact same naive algorithm Jeff warns about in his blog post! Oops! (I've since updated the old article.)

After learning of the problems with the naive algorithm I decided to spend some time exploring approaches that produce valid distributions. This article shows why the naive algorithm produces less than ideal results and includes code for two alternative solutions. Read on to learn more!
Read More >

Many websites that support user account allow anyone to create a new account, but require new users to undergo some form of verification before their account is activated. A common approach is to send an email to the newly created user with a link that, when visited, activates their account. This approach ensures that the email address entered by the user is valid (since it is sent to that user's email address). This workflow not only ensures the valid data entry, but also helps deter automated spam bots and abusive users.

In past installments of this article series we've seen how to use the CreateUserWizard control to allow users to create new accounts. By default, the user accounts created by the CreateUserWizard control are activated; new users can login immediately and start interacting with the site. This default behavior can be customized, however, so that new accounts are disabled. A disabled user cannot log into the site; therefore, there needs to be some manner by which a newly created user can have her account enabled.

There are many ways by which an account may be activated. You could have each account manually verified by an administrative user. If your site requires users to pay some sort of monthly fee or annual due, you could have the account approved once the payment was successfully processed. As aforementioned, one very common approach is to require the user to visit a link sent to the email address they entered when logging on. This article explores this latter technique. Read on to learn more!
Read More >

Microsoft's ASP.NET AJAX framework ships with a mere five Web controls: the ScriptManager and ScriptManagerProxy; the UpdatePanel; the UpdateProgress; and the Timer. Previous installments in this article series have examined all but one control, the Timer. As we've seen from the first installment, all web pages that use the framework must have precisely one ScriptManager control on the page. The UpdatePanel control defines a region on the screen whose content is updated via partial page postbacks, and the UpdateProgress control provides visual feedback during the execution of a partial page postback. The Timer control, which is the focus of this installment, raises a postback every time a specified number of milliseconds has elapsed.

The Timer control is useful in scenarios where a portion of the screen needs to be updated every so often. For example, many financial websites display stock quotes that are refreshed periodically. Prior to AJAX, refreshing the stock quote entailed reloading the entire document, which would result in a screen flash and necessitate the browser re-downloading the entire content of the page (even though the only change that has occurred is the stock quote). Using AJAX techniques we can have the page asynchronously communicate with the server to get the latest quote every n millisconds and seamlessly update the quote on screen. The Timer control, along with the UpdatePanel, make implementing such scenarios a breeze.

This article shows how to use the Timer control to trigger a partial page postback every five seconds. It also shows how to start and stop the Timer through both server-side and client-side code. Read on to learn more!
Read More >

When using Microsoft's ASP.NET AJAX framework and an UpdatePanel whose ChildrenAsTriggers is set to True (the default), anytime a user interface element within the UpdatePanel would normally cause a full page postback, a partial page postback is performed instead. For example, clicking a Button Web control or selecting a different item from a DropDownList control whose AutoPostBack property is set to True normally causes a full page postback, but if these controls are within an UpdatePanel, a partial page postback occurs instead. But what happens if a partial page postback is taking a while to complete and the user triggers the partial page postback again? Or what if during this lull she clicks some other Button in the same UpdatePanel, thereby causing a second partial page postback to ensue?

If a partial page postback is made from the same UpdatePanel while a partial page postback is ongoing, the first partial page postback is aborted and the second postback commences. Aborting a partial page postback simply means that the ASP.NET AJAX framework on the browser no long listens for a response back from the server for that request. It does not stop processing on the server, or rollback any state changes that may have occurred on the server. Consequently, if on a partial page postback you are inserting records into a database or making some other state change, if a user clicks a Button in an UpdatePanel to instigate a partial page postback, but then clicks the same Button again while the partial page postback is still ongoing, there will be two duplicate records inserted in the database.

There are a couple of ways to prevent the user from resubmitting a partial page postback while it's still ongoing. The most effective way, in my opinion, is to "freeze" the frame by overlaying the screen with a <div> element. (See the final demo in the article, Providing Visual Feedback with the UpdateProgress Control.) Another option is to disable the user interface element that triggered the postback during the partial page postback lifecycle. This prevents the user from resubmitting the partial page postback. Read on to learn more!
Read More >

A common user interface element for entering date values is a popup calendar. For example, virtually all travel and booking websites prompt for dates using a textbox that, when clicked or focused, displays a calendar that hovers above the rest of the content on the page. Upon clicking a date from the calendar, it disappears and the date value appears in the textbox. Some websites require that the date be chosen from the calendar; others allow the user to either type in the date or pick it from the calendar.

There have been two previous articles on 4Guys that examined how to create a popup calendar control from the ground up. In Populating Form Inputs Using the Calendar Control, James Avery showed how to have a Calendar appear in a popup window opened via JavaScript's window.open function. Scott D. Smith showed how to use the Microsoft ASP.NET AJAX framework's PopupControlExtender to display the Calendar control in Creating an AJAX-Enabled Calendar Control. There are also a number of third-party Web control vendors that ship popup Calendar controls, which you can peruse at the Date, Time, and Calendar section of the ASP.NET Control Gallery.

I recently worked on a project that used the free RJS PopCalendar control and was impressed with its features and ease of use. This article shows how to add RJS PopCalendar to your ASP.NET web applications and demonstrates some of its functionality. Read on to learn more!
Read More >

The previous three articles in this series focused on building AJAX-enabled web applications using server-side techniques and controls. For instance, Using the UpdatePanel examined how to define regions on the page that participate and are updated by partial page postbacks; Providing Visual Feedback with the UpdateProgress Control showed how to use the UpdateProgress control to display feedback during a long-running partial page postback.

The ASP.NET AJAX Framework also includes a rich client-side library and event model that enables page developers to create and execute client script and event handlers that integrate with the ASP.NET AJAX Framework. This article starts our examination of client-side development with the ASP.NET AJAX Framework. In particular, it examines the client-side PageRequestManager object, which includes methods and events tied to the partial page postback mechanism. In a nutshell, we can use the PageRequestManager object to execute client-side script immediately before or after a partial page postback.

This article discusses the basics of the client-side PageRequestManager object and includes examples that show how to abort and cancel partial page postbacks as well as how to scroll to a particular location on screen after a partial page postback completes. These working demos are available for download at the end of this article. Read on to learn more!
Read More >

Because multiple users can visit the same web page concurrently, it is possible for a user visiting a data modification page to inadvertently overwrite the modifications made by another user. Consider a page with an editable GridView. If two users visit this page simultaneously from different computers and both edit the same row, whomever saves the first will have her changes overwritten by whomever saves the row last. This type of behavior is known as "last write wins" and is the default behavior for web applications.

"Last write wins" is sufficient in applications where it is very rare for two users to be simultaneously working on the same data. If it is commonplace for multiple users to be modifying the same set of data, you should consider implementing some form of concurrency control. There are two flavors of concurrency control: optimistic and pessimistic. Optimistic assumes that concurrency violations are rare and that if such an error occurs that it's adequate to ask one of the conflicting parties to re-enter their information. Pessimistic concurrency, on the other hand, implements policies to ensure that concurrency violations cannot occur. These policies may add friction to the end user's data entry experience.

Microsoft offers a form of optimistic concurrency control from the SqlDataSource control that can be enabled by ticking a checkbox. This article looks at different types of concurrency control and then shows how to implement the built-in optimistic concurrency control offered by the SqlDataSource control. Read on to learn more!
Read More >