What size form / resolution to use?

I'm working on an app that will have many visual controls in one main
form, although the menu will allow users to get into other screens as
well that will contain visual controls in support of the main form.

Question: what is the "right" size form to use these days? I want to
stuff as many controls as possible onto the form, but I _don't_ want
users to have to use scroll bars to get at them. Is still safest to
use 800x600? Or has most of the world graduated to 1024x768 and above?

Am I thinking about the problem correctly, or are there modern
solutions to this issue that I'm not aware of?

Thanks.

-Paul

[Non-text portions of this message have been removed]

Messages in this topic (2) Reply (via web post) | Start a new topic

.

Are you asking about form size or screen resolution? You're obviously safest deploying with the app tested on a variety of resolutions. That being said, it is very time consuming. If you're in a hurry to get it out there, deploy at several of the most common resolutions. Only testing at one resolution would be a mistake in my opinion. If it's got a lot of controls, make it look good at 1024x768 and a few higher than that. 800x600 would probably require a design change and not worth the trouble. That's how I'd approach it anyway.

There are components out there that can automatically adjust your app to different resolutions. I don't know them offhand but people have posted that info before.

Dave

"Paul A." <amibrokerearthlink.net> wrote:
I'm working on an app that will have many visual controls in one main
form, although the menu will allow users to get into other screens as
well that will contain visual controls in support of the main form.

Question: what is the "right" size form to use these days? I want to
stuff as many controls as possible onto the form, but I _don't_ want
users to have to use scroll bars to get at them. Is still safest to
use 800x600? Or has most of the world graduated to 1024x768 and above?

Am I thinking about the problem correctly, or are there modern
solutions to this issue that I'm not aware of?

Thanks.

-Paul

[Non-text portions of this message have been removed]


---------------------------------
All-new Yahoo! Mail - Fire up a more powerful email and get things done faster.

[Non-text portions of this message have been removed]

Messages in this topic (3) Reply (via web post) | Start a new topic

.

I'm asking about form size, I think, since form size is known and
controllable by the app developer (me). Perhaps my thinking is
fuzzy, but I'm proposing that if I don't want the user to deal with
scroll bars, I have to choose a form size that's identical or smaller
to the screen resolution the user will have his display set to.

At 01:12 AM 9/9/2006, you wrote:

>Are you asking about form size or screen resolution? You're
>obviously safest deploying with the app tested on a variety of
>resolutions. That being said, it is very time consuming. If you're
>in a hurry to get it out there, deploy at several of the most common
>resolutions. Only testing at one resolution would be a mistake in my
>opinion. If it's got a lot of controls, make it look good at
>1024x768 and a few higher than that. 800x600 would probably require
>a design change and not worth the trouble. That's how I'd approach it anyway.
&gt;
>There are components out there that can automatically adjust your
>app to different resolutions. I don't know them offhand but people
>have posted that info before.
&gt;
>Dave
>
&gt;"Paul A." <<mailto:amibroker%40earthlink.net&gt;amibrokerearthlink.net> wrote:
&gt;I'm working on an app that will have many visual controls in one main
>form, although the menu will allow users to get into other screens as
>well that will contain visual controls in support of the main form.
>;
>Question: what is the "right" size form to use these days? I want to
>stuff as many controls as possible onto the form, but I _don't_ want
>users to have to use scroll bars to get at them. Is still safest to
>use 800x600? Or has most of the world graduated to 1024x768 and above?
&gt;
>Am I thinking about the problem correctly, or are there modern
&gt;solutions to this issue that I'm not aware of?
>
>Thanks.
>
&gt;-Paul
&gt;
>[Non-text portions of this message have been removed]
>
>
>---------------------------------
&gt;All-new Yahoo! Mail - Fire up a more powerful email and get things
>done faster.
&gt;
>[Non-text portions of this message have been removed]
>
>

[Non-text portions of this message have been removed]

Messages in this topic (4) Reply (via web post) | Start a new topic

.

Okay, nice statement of the obvious (and no question!). That seems like a pretty clear case of fuzzy thinking to me.

DJS

&quot;Paul A." <amibrokerearthlink.net> wrote:
I'm asking about form size, I think, since form size is known and
controllable by the app developer (me). Perhaps my thinking is
fuzzy, but I'm proposing that if I don't want the user to deal with
scroll bars, I have to choose a form size that's identical or smaller
to the screen resolution the user will have his display set to.

At 01:12 AM 9/9/2006, you wrote:

>Are you asking about form size or screen resolution? You're
>obviously safest deploying with the app tested on a variety of
>resolutions. That being said, it is very time consuming. If you're
>in a hurry to get it out there, deploy at several of the most common
>resolutions. Only testing at one resolution would be a mistake in my
>opinion. If it's got a lot of controls, make it look good at
>1024x768 and a few higher than that. 800x600 would probably require
>a design change and not worth the trouble. That's how I'd approach it anyway.
&gt;
>There are components out there that can automatically adjust your
>app to different resolutions. I don't know them offhand but people
>have posted that info before.
&gt;
>Dave
>
&gt;"Paul A." <<mailto:amibroker%40earthlink.net&gt;amibrokerearthlink.net> wrote:
&gt;I'm working on an app that will have many visual controls in one main
>form, although the menu will allow users to get into other screens as
>well that will contain visual controls in support of the main form.
>;
>Question: what is the "right" size form to use these days? I want to
>stuff as many controls as possible onto the form, but I _don't_ want
>users to have to use scroll bars to get at them. Is still safest to
>use 800x600? Or has most of the world graduated to 1024x768 and above?
&gt;
>Am I thinking about the problem correctly, or are there modern
&gt;solutions to this issue that I'm not aware of?
>
>Thanks.
>
&gt;-Paul
&gt;
>[Non-text portions of this message have been removed]
>
>
>---------------------------------
&gt;All-new Yahoo! Mail - Fire up a more powerful email and get things
>done faster.
&gt;
>[Non-text portions of this message have been removed]
>
>

[Non-text portions of this message have been removed]


---------------------------------
All-new Yahoo! Mail - Fire up a more powerful email and get things done faster.

[Non-text portions of this message have been removed]

Messages in this topic (5) Reply (via web post) | Start a new topic

.

PRIVATE MSG:

I had no reason to ask a further question. I was asked one by you,
and I answered it as best I could, and revealed my thinking in case
it was wrong. Looks like it was OK.

-P

At 05:23 PM 9/9/2006, you wrote:

>Okay, nice statement of the obvious (and no question!). That seems
>like a pretty clear case of fuzzy thinking to me.
>
>DJS
&gt;
>&quot;Paul A." <<mailto:amibroker%40earthlink.net&gt;amibrokerearthlink.net> wrote:
&gt;I'm asking about form size, I think, since form size is known and
>controllable by the app developer (me). Perhaps my thinking is
>fuzzy, but I'm proposing that if I don't want the user to deal with
>scroll bars, I have to choose a form size that's identical or smaller
&gt;to the screen resolution the user will have his display set to.
>
>At 01:12 AM 9/9/2006, you wrote:
&gt;
> >Are you asking about form size or screen resolution? You're
&gt; >obviously safest deploying with the app tested on a variety of
> >resolutions. That being said, it is very time consuming. If you're
&gt; >in a hurry to get it out there, deploy at several of the most common
&gt; >resolutions. Only testing at one resolution would be a mistake in my
> >opinion. If it's got a lot of controls, make it look good at
> >1024x768 and a few higher than that. 800x600 would probably require
&gt; >a design change and not worth the trouble. That's how I'd approach
> it anyway.
&gt; >
> >There are components out there that can automatically adjust your
> >app to different resolutions. I don't know them offhand but people
&gt; >have posted that info before.
&gt; >
> >Dave
> >
> >"Paul A."
> <<mailto:amibroker%40earthlink.net&gt;<mailto:amibroker%40earthlink.net&gt;amibrokerearthlink.net>
> wrote:
&gt; >I'm working on an app that will have many visual controls in one main
> >form, although the menu will allow users to get into other screens as
> >well that will contain visual controls in support of the main form.
>; >
> >Question: what is the "right" size form to use these days? I want to
> >stuff as many controls as possible onto the form, but I _don't_ want
> >users to have to use scroll bars to get at them. Is still safest to
> >use 800x600? Or has most of the world graduated to 1024x768 and above?
&gt; >
> >Am I thinking about the problem correctly, or are there modern
&gt; >solutions to this issue that I'm not aware of?
> >
> >Thanks.
> >
> >-Paul
> >
> >[Non-text portions of this message have been removed]
> >
> >
> >---------------------------------
&gt; >All-new Yahoo! Mail - Fire up a more powerful email and get things
&gt; >done faster.
&gt; >
> >[Non-text portions of this message have been removed]
> >
> >
>
>[Non-text portions of this message have been removed]
>
>
>---------------------------------
&gt;All-new Yahoo! Mail - Fire up a more powerful email and get things
>done faster.
&gt;
>[Non-text portions of this message have been removed]
>
>

[Non-text portions of this message have been removed]

Messages in this topic (7) Reply (via web post) | Start a new topic

.

> I'm proposing that if I don't want the user to deal with
> scroll bars, I have to choose a form size that's identical or smaller
> to the screen resolution the user will have his display set to.

Not that fuzzy! I have dealt with the same concern a while ago. One way
to approach the problem is to set your developing machine to its
highest supported resolution and then visually design your forms and
components. Note the postions and sizes of all forms and components,
and in the OnCreate event of esch form, redefine the sizes and
positions of the forms and controls on the forms, using the relative
sizes and positions at design, in proportion with your screen height
and width.

You may want want your MainForm.Width to equal Screen.Width, and
MainForm.Height to equal Screen.WorkAreaHeight, or whatever your design
width and height multiplied by Screen.Width or Screen.Height divided by
your machine screen settings of width or height:

procedure TMainform.FormCreate(Sender: TObject);
begin
Height := Screen.WorkAreaHeight;
// or Height := round((737 * 768)/Screen.Height);
Width := Screen.Width;
// or Width := round((985 * 1024)/screen.width);
Top := 0; // or round((design top*768)/screen.Height);
Left:= 0; // or round((design left*1024)/screen.width);
end;

In this illustration I would show a full screen version of my MainForm
in any screen resolution, or would keep the same visual presentation of
my my MainForm at design time, proportionnally to my screen resolution.
The second alternative assumes a 1024 X 768 screen settings, on the
developing machine.

Let's say a TPanel dropped on your MainForm is 36 left, 30 top, and
210 height, and 907 width. If you want to keep the same aspect ratio of
your control at runtime in all screen resolution, you redefine the size
and position of the Panel in your TMainForm.FormCreate procedure:

....
with Panel1 do
begin
Left := round((36 * 1024)/Screen.Width);
Top := round((30 * 768)/Screen.Height);
Width := round((907 * 1024)/Screen.Width);
Height := round((210 * 768)/Screen.Height);
end;

HTH

Emmanuel

Messages in this topic (8) Reply (via web post) | Start a new topic

.