>In the object inspector for the PTF OOP book I added a menu to the editbox that displays the object data that allowed the user to select the font and colors of the editbox. Giving the end user control like that makes sense to me. The UT Navigator could use this kind of feature. The browser allows us to select one of 5 font sizes and that can be very good for large blocks of free flowing text.

Exactly what I had in mind. The other objects usually stay pretty much unchanged, so they are not re-read every time (labels first), so they don't need neither resizability nor font size changes in general. The exceptions, of course, are exactly the places where resizing is needed.

>The problems of moving things around to handle label size changes is just not worth the effort IMHO. There are dialogs in a couple of places in VFP samples and the class browser where labels are clipped off by controls when larger fonts are selected.

This goes for complete Windows - just try to choose custom font size. It will work, most of the time, but you may get chopped labels, or even unreachable commandbuttons in any app, not just VFP. Changing font sizes is not bulletproof anywhere in Windows (IMHO, predominant reason is they are made in pixels :).

>I got very tired of fighting foxels for position and sizes in FPW and Win3 and welcomed pixels. Foxels are better suited for what you are trying to accomplish though. For my last two apps I'm requiring the systems to run at least in 1024x768, it's required by what the enduser needs, and that resolution is much more available than it was 4 years ago. Everything we do is driven by the enduser and we just need to best meet their needs.

That's my reasoning, too - a significant percentage of my users are old accountant ladies, who can't decide whether to switch to the next dioptry... so I have to think of them, too.