Kbase P3432: Understanding How Resolution and the System Font Affect Widgets and images
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
11/19/2008 |
|
Status: Verified
GOAL:
Understanding How Resolution and the System Font Affect Widgets and images
GOAL:
How screen resolution affects application geometry?
GOAL:
Why an application display differently in another resolution?
FACT(s) (Environment):
Progress 9.x
OpenEdge 10.x
Windows
FIX:
SYSTEM FONT AND HOW IT AFFECTS WIDGET SIZES
PPU is Progress Portable Unit (for ease in understanding, consider a unit as a character but actually it is a character with vertical decoration needed to draw it as a fill-in. That is, it is the HEIGHT of a FILL-IN, but the WIDTH of an character in that font.).
If using a small font for the system font then there are, for example, 7 pixels for the width of a unit (char) and 26 pixels for the height of a unit(char). Please note that these numbers are for example only. To determine how many pixels are being used at your current system font, display session:pixels-per-row and session:pixels-per-column.
If you are using a large font for the system font then there are,for example, 9 pixels for the width of a unit (char) and 29 pixels for the height of a unit (char). (Again this is only an example). Given this information, if you were to define a button in character units and run it with a small system font then there will be less pixels used and therefore it will be smaller than if you used a large font.
Generally bitmaps are a fixed size. A common size is 32 x 32 pixels. For example, if you use a 32 x 32 bitmap and then you create a button that is defined in character units that the image fits nicely into with a small font it may look fine. But if you then run it with a large font, you will find that more pixels are used per unit (char) therefore your button will be bigger (but your image will stay the same size leaving whitespace in your button).
1)
To avoid this, it is recommended that you define your button also in pixels that it will match your image in size. Now if you compile and run in large or small font it will make no difference in terms of your image not fitting your button. You will still only use a certain number of pixels. Your whole button (all widgets) may be larger or smaller and you may
want to tweak the layout at runtime to make sure widgets look good in relation to a position of
another.
2)
Another solution is to avoid bitmaps (or convert to .ico)and use icons(.ico files). They have a clear background that take on the background color of the widget it resides in. So for instance, if your image no long fits nicely in
your button you will not see a weird gap of a different color but will see just your image in the button. Then you can just adjust the coordinates at which the image is displayed in the button so that it is centered.
This can be done after the button has been realized.
3)
You may want to have a different bitmap for smallfont or largefont.
Often when you change resolution, a new system font is introduced too. Sometimes the layout of your screen will not be exactly what you want. You can also make runtime adjustments based on the session:pixels-per-row and the session:pixels-per-column if you no longer like the way your screen layout looks with a new system font.
This is what Progress does when you run under different resolutions/system fonts.
RESOLUTION
Resolution is used in this case as the number of pixels that are used to build your entire display area (screen). In other words, if you use a resolution of 800 by 600 then your display software is using 800 pixels across the width of your screen and 600 pixels down one column of your screen (height). If you were to change to a higher resolution say 1024 x 760 then you are cramming a lot more pixels into the makeup of your screen therefore the size of a pixel is smaller.
Now given this definition of resolution and using the above example where you have a button and an image that were defined in pixels, then you will find that by going to a higher resolution from a lower one, you will end up using the same amount of pixels but they will be much smaller so your image and button will both shrink i.n size. They will still fit together well however without any gaps. This is how to avoid problems going from one resolution to another.
COMPILED CODE
Up until now, I have addressed the case where you are developing code and compiling it with different system fonts/resolutions. Running COMPILED code (rcode) on a system with a different font may still produce problems. Currently, when you compile and save the rcode with a particular system font, the PPU size is saved in the rcode (even if you originally defined the widget in pixels). Therefore, if you run it on a system with a different system font, you will still have the same problems as if you had defined the button/widget in characters. In the above example, for instance, the button may change size but the image does not and you are left with whitespace. If this is the case then you must use option 2 or 3 to get around this..