Best Practices
As with most development related topics, it’s very easy for us to completely miss the blindingly obvious: things other developers assume is common knowledge is often easily missed whilst traversing the learning curve. This chapter aims to provide us with a collection of key decision areas.
The chapter opens with an explanation of the Windows font technology. Whilst we take fonts for granted, care must be taken when selecting fonts if you are internationalising your application. That said, the basic font information provided by Windows isn’t really much help. I was therefore somewhat grateful when the author introduced me to Microsoft’s Font Property Extension tool – it plugs a gap by providing information relating to each font’s Supported Code Pages and Support Unicode Ranges.
A further discussion covers the concepts of font linking and font fallback: terminology that could easily pass you by. Font linking first appeared with Windows 2000 – it essentially provides a means of negating the need to switch fonts in order to display different glyphs or characters. The author augments this chapter with a few screenshots that depict font linking graphically. Font fallback, on the other hand, allows fonts to rely another font that can be used to display letters from other fonts as and when required. Interestingly, font fallback is essentially hard-coded. That said the author explains how to hack the registry to change the fallback fonts.
We’re all guilty of hard-coding something at some stage in our careers: font names are certainly key candidates for such bad, but commonplace, behaviour. If you were planning to hard code font names for any reason, please think again as Windows can substitute font names, thus making any font name comparisons that you might make rather useless. Another example that we’re all guilty off is string concatenation: such behaviour does not bode well for internationalised applications. Luckily the author offers a solution using String.Format.
The localisation of Exception is covered from a .NET 1.1 and 2.0 perspective. The author introduces us to his own ExceptionFactory, a small class that you are free to use in your own applications in order to manage your localised exceptions.
Most well-written applications make good use of Hot Keys – these are the identified (in Windows Forms) using underlined letters. As you might imagine, Hot Keys create many problems for both manual and automatic translators. The author is once again kind enough to provide us with some of his own code. The HotKeyAssignment class solves many of the problems, not least the human effort required to work out the Hot Keys in the first place – how often have you duplicated a Hot Key? The use of Hot Keys in an ASP.NET application is also considered in this chapter.
Layout of controls in a Windows Form is a trivial process. However, it’s not so trivial if you’re looking to localise the form. For example, given a text box and a label, does the label go above the text box or to the left of the text box? Personally, I’ve always put it above the text box. This is an important design decision as English language descriptions tend to be shorter than their foreign counterparts (such as German, or Welsh). An explanation of the .NET features AutoSize, AutoEllipsis, TableLayoutPanel, FlowLayoutPanel then follows, decorated by many useful screenshots.
Comments