After spending many hours reading everything I could find out about the subject, I come to the following conclusions:
1. New development needs to be high DPI aware
2. Automatic and graceful adjustment based on end user settings
3. Support for XP and all that it might entail
4. Use of default system fonts by default (i.e. Tahoma/Segoe) and sizes
FF built in support, including default and automatic processes for these conclusions is going to be important for me and I know I'm probably asking a lot from a one man development team. Although the FF event model is adequate for now, a richer and expanded event model will likely be needed starting with an event hook for a form before it is created to make any customization choices.
Rick Kelly
Hopefully paulwill get it sorted out. :-[
I'm sure he will. The main question I have is if, using FF, I use Tahoma 9pt, can I have it change over to Segoe when appropriate..
Rick
Quote from: Richard Kelly on March 03, 2012, 11:01:33 PM
I'm sure he will. The main question I have is if, using FF, I use Tahoma 9pt, can I have it change over to Segoe when appropriate..
Rick
Myself and Jose spoke about this a little bit. His cWindow class already automatically uses Tahoma for pre-Win7 systems and Segoe for Win7+. In FF, you assign the fonts at design time so you do not know what version of the operating system your customer will eventually run your application on.
I threw open a suggestion that maybe FF can implement a new control property, something like "FontUpgrade". If set to "True" then in the code generation FF would automatically replace the font specified at design time with the most appropriate font depending on the operating system. Pretty easy to implement actually (famous last words) :)
Quote from: Richard Kelly on February 15, 2012, 11:55:46 PM
After spending many hours reading everything I could find out about the subject, I come to the following conclusions:
1. New development needs to be high DPI aware
2. Automatic and graceful adjustment based on end user settings
3. Support for XP and all that it might entail
4. Use of default system fonts by default (i.e. Tahoma/Segoe) and sizes
FF built in support, including default and automatic processes for these conclusions is going to be important for me and I know I'm probably asking a lot from a one man development team.
This is essentially now all complete. Still a few little things to tweak and test at the various dpi settings. FF itself looks much better now at high dpi settings (without virtualization). Code generation uses Jose's cWindow class that is already high dpi aware.
Quote
Although the FF event model is adequate for now, a richer and expanded event model will likely be needed starting with an event hook for a form before it is created to make any customization choices.
Not sure I understand. What is wrong with doing customization in the WM_CREATE message handler?
If you implement the "FontUpgrade" feature, then you are my fairy godfather and all my wishes have come true....I was thinking of before a window is even created to have some customization options.
Rick
I am not sure how you can customize the window if it is not created yet because the HWND is invalid at that point.
FontUpgrade should be in the next update. :)
The "customization" is in the form of altering the various options that go into the creation of the window before it is created. I know it sounds a bit odd....
RIck
Quote from: Richard Kelly on March 04, 2012, 02:25:22 AM
If you implement the "FontUpgrade" feature, then you are my fairy godfather and all my wishes have come true....
The FontUpgrade feature is now implemented and will be available in the next update. Works pretty cool. The property is assigned on a control by control basis so you can specify exactly what controls you want the font name to change automatically based on operating system.
This is the start of something cool. I can do all my designing with Tahoma 9pt and it will flip over to Seqoe when appropriate AND all my windows and controls get resized. What more could I ask for?