All too often we have to post data to a web server and/or navigate to another page and then sit twiddling our thumbs waiting for the response to come back.  Impatient users will click the 'submit' button again or simply leave the site.  The usual approach to solve this dilemma is to introduce a 'Please wait' page that actually initiates the real request to the server, redirecting upon completion.

Usually, this works fine, but there's got to be something better and easier to implement, right?  Well, without any ingenuity there's nothing out of the box.  Over the years, I've implemented various solutions to this issue, some more elaborate than others.  Perhaps someday I'll blog about what I've done that (I feel) pretty danged awesome to borrow an associate's terminology.

I was perusing (read: catching up on) my RSS feeds today and found a post by Mark Wagner and his proposed solution to the issue - which in many ways is pretty elegant and slick.  His solution (yet to be better packaged as a control) implements a script file and a hidden DIV element on the page that gets rendered in the onbeforeunload event.

One advantage of an intermediate page is that it can effectively prevent the user from 'resubmitting' the page because the user is no longer on the page in question.  Does Mark's solution address issues such as these?  I'm not sure yet, I haven't given it too much investigation.  Is this a valid concern?  I think so.

With a little javascript, a developer can definitly deter and mitigate many of these issues and I believe Mark's approach definitely has merit and is a great solution...I'm excited to test it out!

For the longest time (well, at least since April 2004 when I first installed .Text) I have wanted to add the ability to rate a web posting on my blog.  It hasn’t been until recently, however, that I decided to do something about it.

It wasn’t until I was almost done with the project that I decided to do a Google search for other blog rating controls.  I happened upon a Content Rater control by Scott Mitchell (of aspnet.4guysfromrolla.com.  Scott’s control presents a UI reminiscent of the rating boxes found on Microsoft’s MSDN sites.  Funny – that initially provided me with some of my original inspiration as well.  My rating control’s UI, however, ended up completely different.

As I started in on the project I had an idea of where I wanted to end up and what functionality was desired, so I layed out some design goals:

1. Take advantage of .Text’s ability to be functionally extended without needing to be recompiled.  This one was pretty easy – I really didn’t have to think too hard to make this one work
2. Utilize the .Text framework classes as much as possible, providing deeper integration and consistency with how the blog behaves.  This was accomplished simply by referencing the various Dottext.*.dll libraries and building against them
3. Minimize external dependencies.  I wanted to make sure that all controls and pages were completely contained within my .dll with functionality that was homegrown or natively available in the .NET framework.
4. Minimize the impact of the installation and deployment.  I wanted to make the touch points as small and few as possible.  This greatly increases the ease of adoption.
5. Ensure proper functionality within cached parent controls.  .Text will perform PartialCaching controls (i.e. @OutputCache or [PartialCaching]) to optimize server performance and minimize database hits.  This isn’t without its few drawbacks.  One of my primary goals was to allow my rating control to be placed on the blog’s main page along side each post (via .Text’s Day.ascx control).  This control gets cached and therefore does not accept postbacks (unless the postback just happens to correspond with a cache timeout).
6. Support dynamic graphics for rendering the rating (stars, dots, bars to start with).  I didn’t want to have a plain-ol’ ordinary rating on my blog, but rather a nice, professional presentation.  This called for writing a custom HttpHandler to take the graphics and stream them down to the client browser.  If, however, this turned out to be too lengthy an operation, I could just as easily pre-gen the images and have them on-hand, ready to go.
7. Be able to rate anything on the site: blog posts, comments, stories, images, etc.  I didn’t want to be able to rate only blog posts.  Instead, anything on the site is fair game and should be ratable – even other people’s comments!  Ratings with comments would, in addition, become comments themselves.
8. Be hostable anywhere on the site.  As mentioned earlier, I greatly desired to be able to present the rating along side each post on the blog main page.  This required that I support some properties that otherwise I wouldn’t have; properties that allow you to specify the post link (e.g. permalink) and id of the post in question.

I had a general idea of how I wanted it presented, but I could flesh that out in time and wanted to firstly ensure that I would be able to achieve the functionality desired before diving too deeply into the UI.

Ultimately, I decided to implement it as an ASP.NET WebControl rather than as a UserControl.  This allowed me to distribute a single .dll and not have to worry about an additional .ascx file (or set of files).  Though, perhaps, this limits me to how the control is to be rendered on the client, I feel that it wasn’t that great a sacrifice to make.

Due to how I envisioned the control being used I could not have it postback to itself directly, despite all desires to have such functionality.  Therefore, I decided to have the control pop up a dialog box for the user to rate the post.  I’m not a huge fan of popups my any means, but I feel that in this case they are warranted.  First of all, I didn’t want to redirect the user simply to rate the page, and second, it should be a really quick operation.

In order to have a page to display (without distributing any additional files) I had to create a class that inherited from System.Web.UI.Page and drive the UI fully from within the class.

Once this functionality had been defined and the behaviors established, it was time to integrate it with my .Text blog – which will be the topic for my next post.

I found out about this a few months ago and it worked once for me then, but it's failed ever since then until today.  Granted, I've not been checking every day, but occasionally.  Microsoft has created the MSN Web Messenger that allows you to IM w/o any download of an executable.  A particularly beneficial advantage of the WebMessenger is that it enables individuals that are behind blocking firewalls to exchange messages as by using port 80.  I had occasion, back when I first learned about it, while at a client site to use the WebMessenger.  This particular client, a military site, had all the messenger ports blocked on the firewall, but the WebMessenger allowed me to communicate with my contacts which was a life saver (especially since I was out of cell-phone range and email was simply too slow for the information I needed).

Simply login using your MSN passport and you have full access to your contacts, email, etc.  The WebMessenger isn't a fully featured utility app; it only allows for basic chat functionality, but the support it offers is fantastic.  I'm digging it!

Well, it's been a long drought since I last posted here on the blog - for a variety of reasons, but I'm glad to be back at it.  The past weeks (mostly the last one) have been a bit disheartening on several levels; personally, professionally, and extracurricularly, the details of which I will not persue herein.

On a different note, I recently glanced at my blog's web statistics and noticed a significant drop in RSS and Web reads of the blog over the course of several days which left me wondering a few things:

1)  was my blog not accessible?
2)  did a majority of readers simply unsubscribe because the content was not valuable / pertinent/ etc?
3)  are the users simply not opening their RSS readers and downloading subscription data?
3)  insert miscellaneous, random thoughts here

Anyway, I'm back at it, and determined to not let anything get me down or affect the blog.  I am sincerely hoping that the information that thus far I have posted here has been useful in some way to someone other than solely myself.

[Update 11/16/2004 - Fixed grammar, etc]

Following last night's inspiring .NET User Group presented by Scott Golightly (our local Microsoft RD), I've decided to take the plunge.  That is, start developing software (and hence, using my computer) as a non-administrator.  It's a precept that I have long understood and preached, but never practiced - the hypocrisy is over.

All in all, the transition has been painless - nothing has broken in my code which is reassuring.  There were a couple of things, nonetheless, that I had to do to ensure that my development experience remained seameless.

These were the steps that I underwent (more or less):

1.  Removed my domain account from the local built-in Administrators group.
2.  Ensured that my domain account is a member of Debugger Users and VS Developers
3.  In order to properly debug ASP.NET applications I have to ensure that my user account owns the process, so I had to change the credentials under which the aspnet_wp runs.  To accomplish this, I downloaded a tool from Microsoft called aspnet_setreg.exe which allows me to encrypt credentials and such and place them in the registry.  The interesting aspect here is that I have a domain policy in which credentials expire frequently, so I'll have to be updating the registry setting accordingly.
4.  I changed the credentials for the ASP.NET process by editing the machine.config file's tag, updating the username and password attributes to reflect the registry settings.

From that point on, it's all working seamlessly as a matter of fact - which pleases me greatly.

Sure, there are things I have to constantly remember to do, like using RunAs (either via command prompt or context menus) to execute certain actions in an administrative capacity.

A tool that was demonstrated last night that will be extremely helpful is a tool by Aaron Margosis called MakeMeAdmin.  There are certain tasks that need to be executed administratively but not as Administrator.  At times files get installed into user-specific folders or settings need to be made that are user-specific.  Running under different credentials is not adequate.  The MakeMeAdmin (and its counterpart, MakeMePU) temporarily elevates the current user to be a member of the Administrators group to install/change settings.  Very cool!

I ran into an interesting problem that I hadn't seen before, but it was pretty simple to solve.  The problem was manifest by having the Page_Load event firing twice.  At first I was a bit disconcerted.  However after a little thought, I figured it out.

As it turns out, there is an AutoEventWireup parameter on the @Page directive of an ASP.NET page.  The common practice is to explicitly set this to false, thereby enabling developers to be more flexible in naming their methods.  If the parameter is true (or omitted - it defaults to true), then the ASP.NET runtime will automatically 'wire-up' method calls by name (e.g. Page_Load, btnSave_Click, etc).

Well, it turned out that I had both omitted the AutoEventWireup attribute (defaulting to true) and had an explicit event handler (via this.Load += new EventHandler(this.Page_Load);).  Therefore, the event was being called once by the runtime (by virtue of the AutoEventWireup) and once explicitly (by virtue of my explicit event handler).

The reason I never experienced this before was because I either always have the AutoEventWireup=”false” in my @Page directive or, more frequently, I override the OnLoad() method on the page and bypass the event mechanism all together to achieve greater performance.

Today is a pretty exciting day - on a variety of levels.

First (and most importantly) I received my copy of Halo 2.  Now I realize that many enjoyed this thrill yesterday, but my patience has paid off.  The downside is I won't be able to play until later tonight (around 10:00 PM) but it's sitting here on my desk as a constant reminder that I have a date tonight.  I absolutely LOVE the Collector's Edition case - in particular the image on the back cover.  I'm pumped to play it; if you know me, you've known this for a while too .

I'm not a hard-core gamer by trade - never really have been.  But despite the fact that I've owned Halo since I bought my XBox a few years ago, I hadn't passed the stinkin' game until just a couple of weeks ago in anticipation of being ready for part 2.  Now I'm ready!

Second, Mozilla released their very popular Firefox 1.0 browser today.  I've used their 0.9 version for some time as a 'testing' tool rather than my primary browser, but I've always been pleased with it.  Now, I'm not one to back down from my IE devotion.  I've enjoyed being able to take advantage of some of the IE-only extensions in order to create more fully featured, powerful browser-based web applications with great success.  That said, I'm pleased to find that much (but not all) of my code works as expected on this new browser.  I'll continue to use it, and I'd encourage you to do you same, but not as my primary browser - at least not yet.  However, IE 7 is long overdue; IE has been without any significant upgrades or enhancements (aside from the periodic security patch) far too long and I'd like to see something else, something exciting come out of Redmond on the browser front soon.

Hopefully, Firefox is an eye opener for the apparent complacent behavior on part of the MS team.

Though perhaps I'm not as affected as others I know by it, spam is a plague on the net.  I have had my share of garbage spam showing up in my blog and it's been pretty upsettings to find it there.

Today, I was browsing around a bit and found an anti-spam control that I am now fond of.  Miguel Jimenez has put together a small control and an Http Handler that provides a HIP (Human Interaction Proof) mechanism in the form of obfuscated text within an image.  When filling out a form the user must enter the text that appears in the image or else the submittal will not be accepted.

The installation was painless and I had it up an running in less than 2 minutes.  Basically it consists of added a .dll to your \bin, editing the web.config to register the Http Handler (the image generator), and add a pair of tags to the page on which you want to validate the submittal.  The two things that I wasn't really that excited about was 1) that the anti-spam control uses Session state so I had to enable it in the web.config where previously it was off and 2) sometimes the text can be quite difficult to read (e.g. discerning the difference between '$' and 's' can be quite difficult).

All in all, however, the process was seamless and I'm happy about the results.  Good job Miguel!