Understanding fonts and frame-width

Skc

Member
I am currently converting an old Progress V7 Dos application to V9 GUI. In the old DOS application I had the following code which works fine:-

for each myfile with width 80 frame fdetail:
display doc-date invoice trantype doc-no description amount.​
end.


Running the same procedure with V9.1C:

I get a wrap-around of the frame on the screen. DefaultFont used: Verdana Point-size 9. I had to increase the width to something like 'width 110' before it fits nicely without any wrapping.

Can someone explain why this is so? The number of characters of the information shown on screen is < 80, so why does it need a frame of width 110? When we say width 80, does not Progress use the Defaultfont:Verdana, size 9 to do its calculation of the width of the frame? :rolleyes:


Thanks.
 

Dan Dragut

New Member
Hi,

It seems that the DefaultFont from the registry takes precedence over the one defined in the .INI file:

HKEY_CURRENT_USER\Software\PSC\PROGRESS\9.1C\Startup

You can use the recommendations from KB #16962 'Compile problems after Default Font Change' and use

-basekey ini -ininame <your ini file>

as a startup parameter for your Progress client.


HTH,
Dan
 

Dan Dragut

New Member
I realise that I maybe was offtopic, but you didnt't actually say if you recompiled the program using GUI or what font you were using for defining the frame fdetail.

Also, Verdana is not a fixed font, so I guess that Progress uses an average width to calculate the width of a frame character. You should try to use a fixed font like Lucida Console or Courier New.
 

Skc

Member
Yes its compiled using V9.1C GUI. I checked the entry in
HKEY_CURRENT_USER\Software\PSC\PROGRESS\9.1C\Startup
and it shows that the DefaultFont is Ms Sans Serif, Size 8. But this theorectically should not matter because I started Progress with 'prowin32.exe -basekey ini'

This should pick up the PROGRESS.INI which is in my working directory. And what I have specified in progress.ini as DefaultFont is Verdana, size 9.

The font that appears on the screen IS Verdana, size 9. For form design on the screen, most people would use a Variable-font. I also have other screen forms using the same DefaultFont (Verdana). After compilation in GUI, some fields in these forms don't fit the frame and there's wrap-around.

So the problem remains - it appears that Progress calculates the width of the frame based on MS Sans Serif, Size 8 and seems to ignore the DefaultFont I have specified in progress.ini. Anyone have the same experience or know how to force Progress to use MY specified defaultFont for calculation of frame-width?


Regards
Skc
 

ddavisfs2

New Member
I believe that what you will find is that the frame is sized with the default font of the compiling computer. Frame layouts, I believe are done at compile time, so the compiling computer sets the sizing of the frame based on it's default font.

If the computer used to compile this code is set to the same ini file, and it's resolution settings are the same, and it's the same version of windows, it should look the same across clients. If however, you are using different visual settings on the machine that is doing the compiling... unexpected results will occur.

At least that has been our experience.
 

Skc

Member
This is happening with my Development machine using the Progress.ini I have set up in the development machine. I am doing session compile. Application is not yet deployed anywhere else.

If this cannot be resolved, it would mean I have to go thru all the programs and expand the width of most of the screen frames. :(


ddavisfs2 said:
I believe that what you will find is that the frame is sized with the default font of the compiling computer. Frame layouts, I believe are done at compile time, so the compiling computer sets the sizing of the frame based on it's default font.

If the computer used to compile this code is set to the same ini file, and it's resolution settings are the same, and it's the same version of windows, it should look the same across clients. If however, you are using different visual settings on the machine that is doing the compiling... unexpected results will occur.

At least that has been our experience.
 

Skc

Member
Understanding Fonts and Frame-width - EXPLAINED

Skc said:
Can someone explain why this is so? The number of characters of the information shown on screen is < 80, so why does it need a frame of width 110? When we say width 80, does not Progress use the Defaultfont:Verdana, size 9 to do its calculation of the width of the frame? :rolleyes:


Thanks.


I have checked with Progress Australia and Phillip has given a reasonble good explanation. It goes as follows:-



The reason for the behaviour is due to the change in measuring the size of a character between chui and gui. There are two main factors of the change that go around making the behaviour that you see:
1) Font being used is not a "Fixed-font". Fixed fonts are those where all characters are considered to have the same width. These unfixed fonts can have different widths depending on the character (e.g. i would be a have a small width then w).
2) gui assumes you may want to use decorations so allows space for it. This really means that each field displayed via the display statement is considered as a fillin widget rather then text.

To get around these and make it behave more like the character behaviour, you can use the stream-io option in your display commands (it is also available as a compiler option). Here a description of the option:

If you specify STREAM-IO for a frame, the USE-TEXT option is assumed and all font specifications are ignored. The frame is formatted using a fixed font in a manner appropriate for streaming to a text file or printer. In particular, all border padding for FILL-IN widgets is dropped and the default system font is used.

If you use the STREAM-IO option on the COMPILE statement, this behavior is the default for all frames in the procedure. In this case, you can override that option by specifying SCREEN-IO for an individual frame


Conclusion- In GUI, Progress reserves more space for those 'decorations' around fields. Thus several fields that add upto say, 70 characters in a frame would invariably need a total width > 70 characters (assuming no STREAM-IO and regardless of font-size). Which means I do have to change the width of those Screen frames I am converting. :( But at least it is understood. :)

Thanks to those who replied.
Skc
 

ddavisfs2

New Member
Just a thought... You could try to set the default font on the compiling computer to be a font that is wider, but not taller than the font you are intending to use. This would space the frame at compile time wide enough to fit the 70 chars.

I know this might seem a pain, but once the compile is done, it will use the font from the ini of the client to display the frame and may not wrap. This would avoid massive frame code update.

Good Luck!
 

Skc

Member
ddavisfs2 said:
Just a thought... You could try to set the default font on the compiling computer to be a font that is wider, but not taller than the font you are intending to use. This would space the frame at compile time wide enough to fit the 70 chars.


Nope it does not work this way. Compiled a sample program with Verdana,size 9 - leaving the frame width at default 80 (instead of specifying 110) and it was wraparound. Change the progress.ini to Verdana, size 7, start a new Progress session and rerun the compiled program - wordings become smaller but so does the frame and I get exact wraparound as in the first case.

Looks like the frame's width is compiled into the .r code and looks like Progress draws the frame based on the NEW size of the font in progress.ini .

Well - at least we know better how Progress works. :)

Skc
 
Top