Archives
-
Getting disenchanted with Whidbey master pages
I've just started doing some non-trivial stuff with Master Pages in Whidbey, and I'm already hitting some of their annoying limitations. Things that I've hit in just the last hour are:
- Nesting master pages disables the design view. That's right, as soon as you start nesting master pages, you're limited to the HTML code view (in both your master and content pages). That's such a major limitation that it's hard to believe MS even claims nested masters as a feature.
- ContentPlaceHolder controls render themselves as gigantic block elements in the designer, which can not be resized in any way. Essentially that limits their use to defining large regions on the page - forget about using content placeholders in small, precisely positioned regions in a title bar, for example (at least if you want any kind of decent designer experience).
UPDATE - Scott Guthrie comments that that ContentPlaceHolder's will fill their container, and so it's size can be controlled by placing it in a fixed-size container. Unfortunately, that's not the behavior I'm seeing with the Feb CTP - perhaps it's a bug. Also, if you want to design around the natural size of the content, the fill behavior is problematic.
- Nesting master pages disables the design view. That's right, as soon as you start nesting master pages, you're limited to the HTML code view (in both your master and content pages). That's such a major limitation that it's hard to believe MS even claims nested masters as a feature.
-
Log4Net updated
[Via Loren Halvorson]
It seems that Log4Net has finally awoken from it's long slumber, and has been updated - version 1.29 beta (hmm - has there ever actually been a non-beta release?). The great news is that it finally has a proper .NET-style API - no more all-cap constant names, non-camel-cased namespaces (except the root - oh well). inconsistently capitalized abbreviations, etc. Lots of breaking changes there, but it had to happen eventually - the API was just so inconsistent with the framework naming standards that I had to wash my hands after using it. Lots of other improvements, too - details here.
-
SysInternals RSS Feed
Woo-hoo! The SysInternals folks finally have an RSS feed for keeping up with changing in their awesome tools. Subscribed.
-
Things They Didn't Fix in Whidbey - Fonts in Windows Forms
I've been developing with the .NET framework and Visual Studio .NET for several years now. Like most developers, I've accumulated my list of annoyances, hassles, and mistakes that I've encountered using the tools over that time. As an optimistic chap, I cling to the hope that these problems will be addressed in the next version of the toolset.
Well, the next version is here. The improvements are vast, the productivity gains substantial. Naturally, as I've beeng playing with the newest bits (ok, more than play at this point - I'm writing production code on the VS2005 Feb CTP bits), I've been checking to see if MS has addressed any of the problems that have plagued me in the past. Sometimes the news is good, sometimes not. From the title of this post, you can guess which I'm focusing on here. I've already blogged about one such issue. Here's another.
In the .NET Framework 1.x, Windows Forms is really the poor step-child to Web Forms. Yes, MS gave us a reasonably nice object-oriented GUI framework for rich client apps. But let's face it - apps generated with the out-of-the-box controls are the equivalent of circa-1995 Windows applications. One particularly egregious issue with Windows Forms 1.x is with default font handling. Specifically, a Windows Forms application uses the Microsoft Sans Serif font for its controls when running on Windows XP rather than Tahoma, the default system font for XP.
Why is Microsoft Sans Serif used? If you use Reflector to poke in the Control class, you'll find a property called DefaultFont. This is the font that is used if the font isn't explicitly set on the control or its parent. Looking through the source for the property getter, you'll find the following key line of code:
IntPtr ptr1 = UnsafeNativeMethods.GetStockObject(0x11);
So what is stock object 0x11 (decimal 17)? In WinGDI.h, this corresponds to DEFAULT_GUI_FONT. If you look at the MSDN help for GetStockObject, it all becomes clear. Or, maybe not. The first line of help for DEFAULT_GUI_FONT is "Default font for user interface objects such as menus and dialog boxes". OK, that sounds right. Unfortunately, the second two sentences say "This is MS Sans Serif. Compare this with SYSTEM_FONT." So that explains why MS Sans Serif.
Jump down to the description for SYSTEM_FONT, however, and you'll see the following: "By default, the system uses the system font to draw menus, dialog box controls, and text". Erm. Hmm. That sounds familiar, doesn't it? The next two lines clarify "Windows 95/98 and Windows NT: The system font is MS Sans Serif. Windows 2000/XP: The system font is Tahoma".
So it looks suspiciously like someone at Microsoft simply plugged the wrong value into GetStockObject. Now, I'm not a Win32 GDI expert, so maybe there's some history here that explains why they used DEFAULT_GUI_FONT instead of SYSTEM_FONT (Raymond, are you out there?).
OK, so here comes Whidbey. Windows Form 2.0. Finally, Windows Forms gets first class treatment. Slick look-and-feel, richer control set, ClickOnce deployment - MS starts pushing the Smart Client in a big, big way. So of course they're going to fix this font thing, right? Bzzt, sorry, wrong, thank you for playing. No, Windows Forms in Whidbey still uses MS Sans Serif as the default font. In other words, the newest generation of Microsoft's premiere development tool, on Microsoft's latest development platform, generates UIs that don't follow their own UI guidelines.
In all fairness, I'm assuming that MS couldn't change the default font to maintain backward compatibility with existing .NET apps. There's a Ladybug report on this issue describing how to deal with the problem in code, but it's a hack, and there's not a good design-time solution. A small bit of good news is that the new MenuStrip control uses the correct font.
Ideally, I think design-time font selection should work much like color selection, allowing you to select a system font or a custom font. In fact, I started writing a TypeConverter to give you this, but ran into a bug that prevents you from overriding a class TypeConverter with a property TypeConverter. So for the moment there doesn't seem to be a great solution.
-
Visual Studio 2005, Web Sites, and Test-Driven Development
After doing lots of spiking and visual design on a Visual Studio 2005 web site project, I set out to write some production code for the site. I've done some TDD-based component development already on this project, but this was my first foray into writing actual logic (humble dialog style) in the web site project itself. It didn't take long to hit a big snag.
I typically like to put my unit tests in the same assembly being tested. That's always worked well in VS2003, even in web projects, so my first thought was to take the same approach in VS2005. The flaw in that plan is that "building" the web site doesn't generate an assembly that I can point the NUnit test runner at (the assembly ends up in the Temp. ASP.NET Files folder, which isn't too helpful for testing). Oops.
The only solution I've come up with so far is to put the testable UI logic in a separate assembly. Are there any other options that I'm missing?
-
Wow, it finally happened
The good news is that MS finally released their very first ever service pack for a Visual Studio .NET product.
The bad news is that it's Visual Studio .NET 2002 SP1. Presumably VS 2003 SP1 is right around the corner.
And perhaps we shall be free of The Woe at last.