Archive for the ‘.NET’ Category

WebLinkLabel Windows Forms Control

While I was updating my PopupNotify control today, I realized that I had created another useful little control for XBList that I hadn’t released, the WebLinkLabel Control. This simple control wraps the standard LinkLabel control to make it easier to embed multiple hyperlinks in a label, each of which will load up a URL in the user’s default browser when clicked. It’s not the most complex thing in the world, but it has proven useful for inserting help links into XBList’s error dialogs, so I suspect it might be of some utility to others. Using it is about as simple as using a standard Label. Just drag the WebLinkLabel onto your form, customize it however you like, then assign a specially-formatted string to the Text property. You use “url” tags to specify where you want links, like this: “Hello, this is text <url=http://brh.numbera.com>with a link in it</url>.” You can of course have as many links, pointing to as many different URLs, as you would like. If you want to get that formatted string back out, use the LinkText property, or if you want to get a flattened view out (”Hello, this is text with a link in it.”), use the Text property.

This code is licensed under the LGPL, like the other XBList bits I’ve released. As usual, I would appreciate it if whoever uses this code would email me to let me know how they’re using it, just for my own amusement. You can download the control right here.

New Version of the PopupNotify Windows Forms Control

A couple years back I posted the source of XBList’s tray notification control on my site as the PopupNotify control. I licensed it under the LGPL so people could use it for their own applications. While I requested that whoever used it should let me know, I’ve never received any email about it until this week, when somebody wrote to tell me that they had been using it but it didn’t work on Vista, and they wanted some help getting it to work. Despite the fact that I would rather they had told me about this beforehand, I’ve taken this as an opportunity to update the component. I just pulled out the current version of the control that I’m using for XBList, which has a much prettier Vista-style look, less P/Invoke calls, and other .NET 2.0 improvements. I’ve left the 1.1 version of the control around for anyone who wants to use it but hasn’t updated to .NET 2.0 yet.

The new, Vista-style popup

Hopefully this component will continue to be useful to other developers, and they’ll let me know if they’re using it in their projects, since it’s just so much more fun to release stuff for free when you get to see it in action.

Setting the correct default font in .NET Windows Forms apps

I was working on XBList the other night when I realized something - the font used in its dialogs and the friends list wasn't Segoe UI. Segoe UI is the very pretty, ClearType-optimized new default dialog font in Windows Vista. In Windows XP and 2000, it's Tahoma, and in earlier editions it was Microsoft Sans Serif. You can see the subtle differences between them:

Microsoft System Fonts

In .NET and Windows Forms, the default font for controls is actually Microsoft Sans Serif, not the operating system's default dialog font! Kevin Dente explains this on his blog. This is not the only time Microsoft's dropped the ball on this - if you go through some dialogs in Vista you'll see that many of them use Tahoma or even Microsoft Sans Serif instead of Segoe UI. This is pretty funny, especially when Rule #1 of the Top Rules for the Windows Vista User Experience is "Use the Aero Theme and System Font (Segoe UI)". Mitch Kaplan offers up a pretty good explanation for why getting it all right is very hard, but having a mix of old and new fonts still looks shoddy.

I don't want my apps to look shoddy. Embarrassingly enough, I've been hardcoding Tahoma in all my apps to get the more "modern" XP look. Now that Vista's on the scene, it's clear that I want to select the correct default font for whichever OS my app is running on. As Kevin points out, Control.DefaultFont is no help here - it's what's driving Windows Forms' default choice of Microsoft Sans Serif in the first place. After some digging I found this Visual Studio feedback ticket (sign in required), where the Visual Studio guys explain that, while they couldn't fix the default, they did create a SystemFonts class to help out. They recommend putting this code in your Form's constructor:

C#:
  1. this.Font = SystemFonts.DialogFont;
  2. InitializeComponent();

Unfortunately, this doesn't work in a number of ways. The first is that on Vista, SystemFonts.DialogFont is... Tahoma! Closer, but not quite right yet. If you pop open SystemFonts in Reflector, you'll see that the DialogFont property just does some simple platform-detection, and then just hardcodes Tahoma. This worked when it was just 2000/XP vs. 9x, but Vista throws it for a total loop. Fortunately the fix is easy - use SystemFonts.MessageBoxFont instead. This one seems to always return the correct default dialog font.

However, I ran into one more problem. If I set the default font on the Form, like the code above does, I get weird, bloated controls:

Setting the default font on the form screws up controls

Fortunately I've got a solution for that one too. Instead of setting the font on the Form and letting it inherit, just loop through the Controls property, and individually set the right font on each control:

C#:
  1. // Set the default dialog font on each child control
  2. foreach (Control c in Controls)
  3. {
  4.     c.Font = SystemFonts.MessageBoxFont;
  5. }
  6.  
  7. // Use a larger, bold version of the default dialog font for one control
  8. this.label1.Font = new Font(SystemFonts.MessageBoxFont.Name, 12f, FontStyle.Bold, GraphicsUnit.Point);

Now I get a more familiar-looking dialog:

Setting the default font on each control looks fine

I could always make a subclass of Form to do this for me, but I'm OK with copying it into each new form. With this code, all my controls come up with the pretty new Segoe UI font in Windows Vista, and Tahoma in XP.

Using MyODBC with ASP.NET in IIS7 on Vista x64

That's a heck of a title, but it's a problem I hit recently. I have a bunch of ASP.NET sites that use MySQL as their datastore, but I hadn't tried the on IIS7 yet. It took a while to get them to work at all (I had to set permissions on web.config and the other website files so that they could be read by both the Users group and the IIS_IUSRS group), but then I was left with an error about my MySQL connection. "ERROR [IM002] [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified" - another very general error that basically means "Something is wrong with your ODBC driver, somewhere."

After some searching, I learned two things. The first is that if you're running 64-bit you can't use the standard ODBC Data Source Administrator in Administrative Tools with MySQL. You've got to go to C:\Windows\SysWOW64\odbcad32.exe and set up your DSN, if that's your thing. The other thing is that the MyODBC driver is 32-bit only. So to use it at all, you need to make sure you're calling it from 32-bit apps only. That means you've got to tweak the Application Pool you're using to run all its ASP.NET applications as 32-bit. To do this, go to Administrative Tools > Internet Information Services (IIS) Manager (or just hit the Windows key and type "IIS"). Then go to "Application Pools" and select whichever application pool your ASP.NET app uses (or create a new one just for your MySQL apps. Click "Advanced Settings..." and set "Enable 32-Bit Applications". Now the AppPool will use the 32-bit .NET CLR to run your app, and it'll be able to see your MyODBC driver (whether you use a DSN or not).

IIS7 32-bit Application Pool

Creating nested custom configuration sections in ASP.NET 2.0

This weekend I decided to go through the hodgepodge of common code that's shared between a lot of my ASP.NET websites and refactor it a bit. I'd only just learned about the magic of HttpModules and HttpHandlers, and I immediately saw a lot of canidates in my copy-paste code and global.asax handlers where a HttpModule would be a better solution. One of these was the code I was using to redirect old pages to new pages whenever I moved them. For example, at some point I had moved http://www.numbera.com/rome/tools.aspx to http://www.numbera.com/rome/tools/, and I wanted anyone who visited the old URL to get redirected to the new one. Previously, I just had some code in global.asax that hooked Application_OnError, checked to see if it was an HttpException (a 404 file not found, specifically), and then redirected if it knew where the file really was. Pretty simple, but not very general. So I broke it out into an HttpModule that basically did the same thing, but no longer required me to cut and paste code into my global.asax. However, one improvement I wanted to make was to allow for configuration through my web.config file, instead of having to hardcode an if/else tree for each redirect. I basically wanted to have a section in my web.config like this:

XML:
  1. <configSections>
  2.     <sectionGroup name="brh.web">
  3.        <section
  4.          name="redirectOldUrls"
  5.          type="Brh.Web.RedirectConfigurationHandler, Brh.Web.Utility"
  6.        />
  7.    </sectionGroup>
  8.   </configSections>
  9.  
  10.   <brh.web>
  11.     <redirectOldUrls>
  12.       <redirect filePattern="tools.aspx" url="~/tools/" />
  13.       <redirect filePattern="strategy.aspx" url="~/strategy/" />
  14.         <redirect filePattern="military_people.aspx" url="~/people/" />
  15.         <redirect filePattern="history.aspx" url="~/history/" />
  16.         <redirect filePattern="teacher.aspx" url="~/teacher/" />
  17.     </redirectOldUrls>
  18.   </brh.web>

(more...)