Screen resolutions vary among users

[Function G Solutions]

Without actually attempting yet to develop a solution for font sizes and layout difference required for different screen resoltions per workstation, I thought it best to ask about this topic to get a better understanding of what others have done, or what is recommended to address it. I'm talking about how fonts are too small to read on some screens with super hi res display settings. If I changed the layout font on the fly (if that's even possible in FM)then the text would overlay other layout objects, fields, etc. So it seems like I have to create an entirely duplicated set of layouts for the hi res systems, rename them with a prefix of, say, Hres_ or whatever, edit them with larger fonts and rearrange objects to look right, duplicate and edit all scripts to use the hi res layouts, edit button controls to use the right layouts, then setup some resolution test on FM startup to use the hi res layouts. THat is a whole bunch of work and then what about maintenance of both sets of layouts? Holy cow! Any way to do this better? If not, what is the test and method I should use at FM startup to get this done?

I saw Get(ScreenHeight) and Get(ScreenWidth) in the Help file, but I'm not sure those are what I should be using to test screen res. I had a notion of opening a test layout at FM startup, maximizing that window (and the FM program window - would that require a callout to an OpSys command?) and using those Get comands to find the screen res, etc.

I cringe at the whole idea of this issue.

Edited November 10, 2010 by Guest
typo

[Vaughan]

By all means Get( ScreenWidth ) is a good choice to determine what the screen's width is. Get( ScreenHeight ) might also be good because these days the limiting factor is screen height rather than width. Decide which to use and then stick with it.

Use one of these functions in a startup and other layout switching scripts to determine which layout to display. It will require creating and maintaining multiple sets of layouts though which can be a pain.

I tend to create layouts that fit (just) on the smallest supported desktop, and use auto-resize to take advantage of the larger area if the user makes the window larger. Currently my layout dimensions are a bit under 1024x768 and sized for FMP 10/11 on Windows 7 which seems to have the most screen decoration.

Note that I used the word "supported" desktop above. A decision has to be made what NOT to support. My bottom line is to support laptop computers and a 1024x768 window displays almost full screen on an old 11 inch laptop, is a comfortable fit on a 13 inch screen, and allows for multiple windows and some re-sizing on a 15 inch.

I'm not a fan of maximising all windows in Windows.

[Function G Solutions]

AhhhhhhHa! Auto resize, for some reason I missed that one. I'll have to investigate that further. If it's anything like sliding objects and whitespace for printing, there is some tweaking involved and using the feature can sometimes affect the layout design. For instance, I found it more effective in getting pretty results to put my State and Postal Code below the City for an address layout when printing. I think it was partially due to being in a hurry at the time with the boss breathing down my neck to get a packing slip ASAP. I guess I should revisit that layout to see about getting slide left to work the way I want it to.

Thanks for the tips. I think I will avoid doubling up on layouts, and go with your general method of deciding what to support and building for the lowest res with objects set to auto-resize. Time spent getting to know the auto-resize affectations is applicable to all future designs, whereas double-dealing two sets of layouts seems like a lot more work than it's worth. I could be sailing or hiking or discovering more about scripting

George Szynal

Function G Solutions

Albuquerque, NM