Skip to main content

[archive] Screen sizing - any tips?

  • July 21, 2009
  • 5 replies
  • 0 views

[Migrated content. Thread originally posted on 17 July 2009]

I've always coded for 800x600 and 1024x768 screens and have identified which is active on the user's machine via the command:

accept terminal-abilities from terminal-info

I then look to the PHYSICAL-SCREEN variables and make a determination on how to size my screen and some of the controls on it.

The problem surfaces with font size manipulation and the subtle differences between the 8 million Windows OS variations and themes. What works for one setup may cause scroll bars to appear on the next...and I need to have the scroll bars so that access to all areas of the screen remain.

So I'm just looking to see what others out there have done to handle this when they want to maximize their screen space?

Can we even programitically determine if scroll bars exist at which point I can dynamically make screen changes?

5 replies

[Migrated content. Thread originally posted on 17 July 2009]

I've always coded for 800x600 and 1024x768 screens and have identified which is active on the user's machine via the command:

accept terminal-abilities from terminal-info

I then look to the PHYSICAL-SCREEN variables and make a determination on how to size my screen and some of the controls on it.

The problem surfaces with font size manipulation and the subtle differences between the 8 million Windows OS variations and themes. What works for one setup may cause scroll bars to appear on the next...and I need to have the scroll bars so that access to all areas of the screen remain.

So I'm just looking to see what others out there have done to handle this when they want to maximize their screen space?

Can we even programitically determine if scroll bars exist at which point I can dynamically make screen changes?
We have come up with some standard screen sizes and have our own themes affiliated with the screen sizes. So for each theme, users can change the fonts, etc. associated with it and customize it for their own needs. Our four standard themes work under most circumstances, but can be easily changed by the user.

[Migrated content. Thread originally posted on 17 July 2009]

I've always coded for 800x600 and 1024x768 screens and have identified which is active on the user's machine via the command:

accept terminal-abilities from terminal-info

I then look to the PHYSICAL-SCREEN variables and make a determination on how to size my screen and some of the controls on it.

The problem surfaces with font size manipulation and the subtle differences between the 8 million Windows OS variations and themes. What works for one setup may cause scroll bars to appear on the next...and I need to have the scroll bars so that access to all areas of the screen remain.

So I'm just looking to see what others out there have done to handle this when they want to maximize their screen space?

Can we even programitically determine if scroll bars exist at which point I can dynamically make screen changes?
I don't know if this will help or not, but I first determine the ablsolute min size the window can be say 800X600 and design the screen around that. Then use the LAYOUT-MANAGER = LM-RESIZE on all the controls and make the window resizable. This way the user can drag the screen or double click the title bar to maximize it to their preferred size.

When a user exits the screen, the height and width are stored in a config file for the user, so that when they use the application each time it maintains thee correct size for them. We are still using 6.1.1, but I see from looking at 8.1 that this process is much easier and more integrated with acubench.

It's a lot of work to get it to function initially so that all the controls resize and move properly, but once it's done it works great.

[Migrated content. Thread originally posted on 17 July 2009]

I've always coded for 800x600 and 1024x768 screens and have identified which is active on the user's machine via the command:

accept terminal-abilities from terminal-info

I then look to the PHYSICAL-SCREEN variables and make a determination on how to size my screen and some of the controls on it.

The problem surfaces with font size manipulation and the subtle differences between the 8 million Windows OS variations and themes. What works for one setup may cause scroll bars to appear on the next...and I need to have the scroll bars so that access to all areas of the screen remain.

So I'm just looking to see what others out there have done to handle this when they want to maximize their screen space?

Can we even programitically determine if scroll bars exist at which point I can dynamically make screen changes?
I don't know if this will help or not, but I first determine the ablsolute min size the window can be say 800X600 and design the screen around that. Then use the LAYOUT-MANAGER = LM-RESIZE on all the controls and make the window resizable. This way the user can drag the screen or double click the title bar to maximize it to their preferred size.

When a user exits the screen, the height and width are stored in a config file for the user, so that when they use the application each time it maintains thee correct size for them. We are still using 6.1.1, but I see from looking at 8.1 that this process is much easier and more integrated with acubench.

It's a lot of work to get it to function initially so that all the controls resize and move properly, but once it's done it works great.

[Migrated content. Thread originally posted on 17 July 2009]

I've always coded for 800x600 and 1024x768 screens and have identified which is active on the user's machine via the command:

accept terminal-abilities from terminal-info

I then look to the PHYSICAL-SCREEN variables and make a determination on how to size my screen and some of the controls on it.

The problem surfaces with font size manipulation and the subtle differences between the 8 million Windows OS variations and themes. What works for one setup may cause scroll bars to appear on the next...and I need to have the scroll bars so that access to all areas of the screen remain.

So I'm just looking to see what others out there have done to handle this when they want to maximize their screen space?

Can we even programitically determine if scroll bars exist at which point I can dynamically make screen changes?
When a user exits the screen, the height and width are stored in a config file for the user, so that when they use the application each time it maintains thee correct size for them.


Hi Mikalodeon

How is it possible to inquire the height and width of the current window?
I have tried using

INQUIRE Window Form1-Handle
        SIZE        = CURRENT-SIZE
        LINES       = CURRENT-LINES.

but it does not work.

Regards Kim

[Migrated content. Thread originally posted on 17 July 2009]

I've always coded for 800x600 and 1024x768 screens and have identified which is active on the user's machine via the command:

accept terminal-abilities from terminal-info

I then look to the PHYSICAL-SCREEN variables and make a determination on how to size my screen and some of the controls on it.

The problem surfaces with font size manipulation and the subtle differences between the 8 million Windows OS variations and themes. What works for one setup may cause scroll bars to appear on the next...and I need to have the scroll bars so that access to all areas of the screen remain.

So I'm just looking to see what others out there have done to handle this when they want to maximize their screen space?

Can we even programitically determine if scroll bars exist at which point I can dynamically make screen changes?
Hi Mikalodeon

How is it possible to inquire the height and width of the current window?
I have tried using

INQUIRE Window Form1-Handle
        SIZE        = CURRENT-SIZE
        LINES       = CURRENT-LINES.

but it does not work.

Regards Kim


what you have here is basically what I do except I omit the word 'Window' and don't use the '=' sign, so it's like this:


INQUIRE Form1-Handle SIZE CURRENT-SIZE.
INQUIRE Form1-Handle LINES CURRENT-LINES.