FntDefineFont gotcha

Beware if you use FntDefineFont on the Tungsten T3.  You should be prepared for other applications popping up and redefining your fonts!  In particular, the clock application (which pops up when pressing the select button on the 5-way nav while the device is turned off) redefines the font fntAppFontCustomBase.  When your app gets control back, if you try to use that font, you will get garbage on the screen or your T3 will crash.

The fix that we've implemented is to re-call FntDefineFont whenever we get a winEnter event.  This seems sufficient for this particular case, but theoretically, there could be another background app that redefines the font without even opening another window. (ack!)  In that case, you should call FntDefineFont before using any custom font.  But I'm not going to go that far.

(Even that, if you want to be absolutely safe, is not adequate.  There could be another thread (e.g. an audio callback thread) that calls FntDefineFont, causing a race condition on your code.  This is so unbelievably rare that I think it's ridiculous to worry about.)

The conclusion is that FntDefineFont is broken at the OS level because it allows other applications to mess with your resources.  Custom font IDs should be dynamically allocated.  This has probably been addressed in OS6, but I haven't been paying as much attention to OS6 as I should.