Archive for the ‘.NET’ Category

« Older Entries

Visual Studio debugger is too sensitive about exceptions

Tuesday, January 13th, 2009

I was working on XBList the other day when I hit a peculiarity of Visual Studio. I wanted to call a method asynchronously, so I was using BeginInvoke with a callback, as described in this article on MSDN. So I used BeginInvoke to fire off a method, and the method I invoked happened to throw an exception. I didn’t expect this to be a big deal – when the callback was called, I would call EndInvoke which would re-throw the exception and I could deal with it. However, while running in Visual Studio’s debugger, I got a break and an error dialog that claimed I had an unhandled exception. My code never made it to EndInvoke. It said something like “Exception unhandled by user code”.

It turns out that this is just some weirdness in Visual Studio. If you go to the Debug menu, choose “Exceptions…”, and uncheck “User-unhandled” for Common Language Runtime Exceptions, the exception will get properly thrown when EndInvoke is called, and everything’s fine.

exceptions-setting

It’s annoying that I have to give up the relatively useful unhandled-exception trapping that the Visual Studio debugger gives me, but I guess there’s no other way around it.

Tags: , , , ,

Posted in .NET | View blog reactions | No Comments »

Posts I haven’t written

Tuesday, October 14th, 2008

I haven’t been updating this blog too much recently. I never meant for this blog to run on a schedule, but I did intend to post more frequently than this. My original idea was that the blog would serve two major purposes. First, it is a place for me to announce new projects or updates to software and websites I’ve already released. It’s done that quite well, though I haven’t had much to announce recently. My job has been taking the majority of my development time, and most of the projects I’ve been working on at home are either private or haven’t been released in the form I’d like to because my employer hasn’t approved them for release yet.

The second major purpose for my blog is as a place for me to record the solution to problems I run across while developing software, so that others won’t have to spend hours Googling or using trial and error to come to the same conclusion. I didn’t intend to rehash things that were easily found or that had already been discussed – only to post when I felt it was something that added value to the internet that hadn’t been there before. So a lot of the blog posts are not really a narrative or running commentary – they’re not meant to be subscribed to, but found individually. It’s for this reason that my most popular posts tend to include the exact text of error messages. This type of post has suffered both because I haven’t been doing as much development, because I can’t discuss a lot of what I’ve learned due to the nature of the projects I’m working on, and because I’ve been learning new stuff (like Ruby on Rails) and haven’t done enough to have solved problems others haven’t already posted solutions for.

The third reason I have this blog is to occasionally talk about my thoughts on different technical topics, from web development to video games. Again, I don’t like to make a post unless I think I’m adding something new, and most of the topics I’ve wanted to talk about have already been covered. I had a lot of draft posts sitting around about web development, web standards, and the evolution of browsers, but then I discovered Alex Russell’s blog and it turns out he’s already said most of what I wanted to say, and better than I could. Other stuff, like my impressions of Windows Vista, critique of stackoverflow.com and suggestions for the Xbox Live Arcade lineup, have been covered to my satisfaction in plenty of places. Maybe some of them will end up posted, but probably not.

Another part of the reason I haven’t posted much is the sheer weight of unfinished posts I have. Right now I have 64 drafts and only 52 real posts! So I’m going to attempt to clear things out by writing a little about what I haven’t posted. A lot of this stuff wasn’t posted because it fell under that third point above, but some of it I was just too lazy to flesh out into real posts. Some of it’s just random stuff. So here’s what’s been happening in the last year:

(more…)

Tags: , , , , , , , , , , , , , , , , ,

Posted in .NET, Apple, BenHollis.net, Java, Programming, Random, Web, Windows | View blog reactions | No Comments »

WebLinkLabel Windows Forms Control

Sunday, September 9th, 2007

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.

Tags: , ,

Posted in .NET | View blog reactions | No Comments »

New Version of the PopupNotify Windows Forms Control

Sunday, September 9th, 2007

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.

Tags: , , ,

Posted in .NET | View blog reactions | 5 Comments »

Setting the correct default font in .NET Windows Forms apps

Wednesday, April 11th, 2007

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:

PLAIN TEXT
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:

PLAIN TEXT
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.

Tags: , , ,

Posted in .NET | View blog reactions | 10 Comments »
« Older Entries