[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!

Several months ago I wrote an article on enabling XP Visual Styles in your .NET 1.1 applications via a method called EnableVisualStyles().  This method, when coupled with a subsequent call to DoEvents() to work around a bug in the implementation of EnableVisualStyles() provided the nice, attractive Windows XP look and feel to which we've all grown accustomed.  If you fail to provide the DoEvents(), you will be greeted with an SEHException() that is not quite informative and can leave you scratching your head.

The alternative to this approach is to fall back to what was required in the good old days of .NET 1.0: that is, we must create a .manifest file.  Including the .manifest file along with your application is not very desirable.  A convenient, but painstaking remedy, is to embed the .manifest file xml directly into your executable post-build.  Simply open your executable in Visual Studio, add a new resource of the type RT_MANIFEST and paste your content.  Assign a resource id of 1 and change the Language to Neutral.  At this point you'd be good to go.  This process can be automated via code if you like as well.

These approaches are documented ad nauseum across the internet, so I won't consume any more time eating bandwidth on how they work (a simple Google search will provide all the answered you could want - and more).

One might ask, however, why on earth would I want to go through all the trouble of using a .manifest file (embedded or otherwise) when I have the option of using EnableVisualStyles()?  Well, the short answer is that EnableVisualStyles() doesn't fix the whole problem.  As it turns out, the issue resurfaced for me again this evening.

There is still an issue with respect to ComboBoxes and XP styles.  If you call a DoEvents() or show a dialog from a ComboBox event (such as KeyPress or SelectedIndexChanged) the SEHException will be thrown.  For example, consider the following code:

private void cboSearch_KeyPress(object sender, KeyPressEventArgs e) {
   if ( e.KeyChar == (char)Keys.Enter ) {
      e.Handled = true;
      doSearch();
   }
}

private void doSearch() {
   pnlStatus.Visible = true;
   Application.DoEvents();   // make sure the panel is fully visible before proceeding
   try {
      // ...search logic here...
   }
   finally {
      pnlStatus.Visible = false;
   }
}

So there seems to be a remedy in code, but I can't say that I really recommend it as a best practice.  The best way (i.e. the least error prone) is to go the route of the .manifest file, but it's not without its complications and gotchas.  I would much prefer to use the EnableVisualStyles(), and now that I know of a way to work around the issues until fixed I can live with it.

If you're like me in your GDI+ adventures you've run across the Image.GetThumbnailImage(...) method and been disappointed with its results.  This method opts for performance over quality when rendering your thumbnail image and as a result your thumbnails can look discolored or distorted.  I wanted to have a routine that provided a high performance alternative but would render a better quality image.

The way I implemented this at first was to iterate through the pixels of the source image, performing averages of pixel color over an area of pixels, and writing that resultant pixel to the output (thumbnail) image.  I wrote this a couple of years ago and it did the trick nicely and for a small number of small pictures it was more than adequate; with larger pictures, on the other hand, the performance degradation was noticeable.  I've attached the code for your viewing pleasure:

public static Bitmap CreateThumbnail(Bitmap source, int thumbWi, int thumbHi, IProgress progressCallback) {
   if ( thumbWi > source.Width || thumbHi > source.Height ) return null;

   Bitmap ret = new Bitmap(thumbWi, thumbHi);
  
   float xScale = (float)thumbWi / ((float)source.Width - 1);
   float yScale = (float)thumbHi / ((float)source.Height - 1);

   for ( int i = 0; i < thumbHi; i++ ) {
      for ( int j = 0; j < thumbWi; j++ ) {
         int x1 = (int)( j / xScale );
         int x2 = (int)( ( ( j + 1 ) / xScale ) - 1 );
         int y1 = (int)( i / yScale );
         int y2 = (int)( ( ( i + 1 ) / yScale ) - 1 );
         float r = 0, g = 0, b = 0;
         for ( int x = x1; x <= x2; x++ )
            for ( int y = y1; y <= y2; y++ ) {
               int c = source.GetPixel(x, y).ToArgb();
               r += ( c & 0xff0000 ) / 0xff01;
               g += ( c & 0xff00 ) / 256;
               b += ( c & 0xff );
            }

         int numPixels = ( x2 - x1 + 1 ) * ( y2 - y1 + 1 );
         ret.SetPixel(j, i, Color.FromArgb((int)( r/numPixels ), (int)( g/numPixels ), (int)( b/numPixels )));
      }

      if ( null != progressCallback ) progressCallback.Report(i / thumbHi * 100);
   }

   return ret;
}

Recently, however, it became important to have a faster algorithm to generate image thumbnails.  To meet these new demands, I produced the following code which results in as good a thumbnail as my previous code but MUCH faster - though not quite as fast as the GetThumbnailImage(...) method.  Here is its code:

public static Bitmap CreateThumbnail(Bitmap source, int thumbWi, int thumbHi) {
   // return the source image if it's smaller than the designated thumbnail
   if ( source.Width < thumbWi && source.Height < thumbHi ) return source;

   System.Drawing.Bitmap ret = null;
   try {
      int wi, hi;

      // maintain the aspect ratio despite the thumbnail size parameters
      if ( source.Width > source.Height ) {
         wi = thumbWi;
         hi = (int)(source.Height * ((decimal)thumbWi / source.Width));
      }
      else {
         hi = thumbHi;
         wi = (int)(source.Width * ((decimal)thumbHi / source.Height));
      }

      // original code that creates lousy thumbnails
      // System.Drawing.Image ret = source.GetThumbnailImage(wi,hi,null,IntPtr.Zero);
      ret = new Bitmap(wi, hi);
      using ( Graphics g = Graphics.FromImage(ret) ) {
         g.InterpolationMode = System.Drawing.Drawing2D.InterpolationMode.HighQualityBicubic;
         g.FillRectangle(Brushes.White, 0, 0, wi, hi);
         g.DrawImage(source, 0, 0, wi, hi);
      }
   }
   catch {
      ret = null;
   }

   return ret;
}

Enjoy!...and happy thumbnailing!

In developing pages and controls in ASP.NET I've come across situations in which I need to bind against properties that are not implemented on the default interface of the object in question.  For the most part, this is really never an issue.  Typically you have an object (be it a user-defined class instance, or something more data-centric such as a DataSet or a DataReader) and you want to bind against it.  Your syntax might frequently resemble the following:

<%# DataBinder.Eval(Container.DataItem, "UserName") %>

where this code will evaluate (via Reflection) the item being bound (identified by Container.DataItem) and extract the value contained within the UserName property/column/etc.  This is all well and good and usually all that you need.  However, only properties (and methods) on the default interface are sought.  That is, if your object (Container.DataItem) implements and interface and maps to the interface methods directly rather than implementing them generically by name, the runtime will not be able to resolve to them.

For example, suppose you have an IUser interface defined and implemented within a User class:

In this scenario, your databinding would work perfectly.  Yes, UserName maps to the IUser.UserName property implicitly, but is also defined on the default interface for User.  Suppose, however, that the implementation were explicit:

There, works like a charm.  Note, that depending on the content of the property, you might be best served by enclosing the operation in a Server.HtmlEncode() function call to prevent any misuse, XSS (Cross Site Scripting), or HTML/Script injection.