Re: Screen resolution problem

Tech-Archive recommends: Fix windows errors by optimizing your registry

Hi Steve,

I think your idea will work quite easily. I figured out what my
form min width and height could be to still properly display my
grid and a frame that houses a third of my controls. The grid is
the only control I have to resize.

Here is what my code looks like so far...I have a few more to
do. Thanks! Thanks for the thread discussion everyone.

Private Sub Form_Resize()
If frmMain.Width < 11415 Then frmMain.Width = 11415
If frmMain.Height < 8550 Then frmMain.Height = 8550
vsRules.Width = frmMain.Width - 585
vsRules.Height = frmMain.Height - 4605
cmdAdd.Top = vsRules.Top + vsRules.Height + 105
cmdNew.Top = vsRules.Top + vsRules.Height + 105
cmdEdit.Top = vsRules.Top + vsRules.Height + 105
cmdMove.Top = vsRules.Top + vsRules.Height + 105
cmdUncheck.Top = vsRules.Top + vsRules.Height + 105
cmdDelete.Top = vsRules.Top + vsRules.Height + 105
End Sub


"Steve Barnett" <noname@xxxxxxxxxxxx> wrote in message
news:OOAKyYXiGHA.3816@xxxxxxxxxxxxxxxxxxxxxxx
dman
You can do it at start-up, but why not give the user the chance to
resize the form? It's a perfectly reasonable thing for them to want to do,
after all. And what happens if they resize the desktop size while your app
is running - do they have to close and reopen your app to get the new
size?

If you're only dealing with a small number of controls, then I would put
the code in the resize event and give the users the "full Windows
experience".

For the vast majority of my apps, I create the initial form layout for an
800x600 resolution and the add code to the resize event to move and resize
all of the visible controls if the resolution changes. Most of the time,
very little actually moves - it's generally the case that things either
grow or shrink. For example, say you have a form like this:

[ Title bar ]
[ Menu ]
[ Tool bar ]
Label 1 with instructions
Some buttons
Large data entry grid
[ Status bar ]

In this case, the menu, toolbar and status bar all take care of
themselves, because they're docked to the edge of the form. I need to
provide code that changes the width of the label (not its position, as
that's fixed) and the width and height of the data entry grid (again it's
position is fixed). The buttons won't move - there isn't much you can do
about them.

For my minimum form size, I'll pick a value that ensures that I can keep
all of the buttons visible and two or three rows of the grid (you need to
experiment on this).

I don't usually bother to mess with font sizes as the difference between
800x600 and 1280x1024 isn't sufficient to bother and any smart arse with a
higher resolution deserves all they get for having better eyesight than me
(Joking).

What it does mean is that, if I need to open another app and look up some
information, I can keep the app open while I look at information in
another app, side by side. This might not be appropriate for you (now).
However, if you're writing the code to resize the form at start-up, why
not put it in the resize event and do it whenever the form resizes.

Steve


"dman" <unlisted@xxxxxxx> wrote in message
news:%23JSK5fWiGHA.3780@xxxxxxxxxxxxxxxxxxxxxxx
Hi Steve.

Would I want to put the code in the resize event?

What if I check the screen resolution upon app startup and run my
code to init the form then. I wasn't planning on letting them
resize the form by dragging it - only min and maximize.

Are you suggesting that I use a calculated position for each
control depending on the screen resolution and the size of the form?

I'm still a little confused on that point.

Thanks.
D

"Steve Barnett" <noname@xxxxxxxxxxxx> wrote in message
news:OG5kjsTiGHA.4504@xxxxxxxxxxxxxxxxxxxxxxx
Guess everyone else has made the point. Given your description of the
form, I think it would be madness to create a second form... use the
resize event to resize the content of the single form.

I think of it this way... if I have to create a second instance to
support 800x600 then I'll need a third instance to support 1280x1024 and
a fourth for 1600x1024 and so on. I then find a bug or the user asks for
a small change and I find myself with a nightmare of a maintenance job.
Using the resize event means that I only retain a single copy of the
code to maintain.

Some points to be aware of... the resize event will fire when the form
is minimised, so be careful to check for this and to not resize the
contents when the form is minimised. I also code for a "minimum
resolution". Once the user can resize the screen, they'll shrink it to
see how small it will go.. What I do is decide on an arbitrary size that
is as small as I want to go and then stop resizing the controls if the
user shrinks it any smaller. It's not entirely user friendly, but I like
to tell myself that I'm protecting them from themselves.

Steve



"dman" <unlisted@xxxxxxx> wrote in message
news:OFAkNoNiGHA.412@xxxxxxxxxxxxxxxxxxxxxxx
I think my 2 options are....

1. Create a 2nd smaller form and load it if screen is 800*600

2. On the fly, resize form and move controls. There is only 1
control(grid) that I would need to resize, everything else can just
be moved.


"Ralph" <nt_consulting64@xxxxxxxxx> wrote in message
news:qt2dnehsresYGBnZnZ2dnUVZ_rmdnZ2d@xxxxxxxxxxxxxxx

<snipped>

Depending on the size and architecture of your app , you might also
consider
merely creating separate forms for each resolution (one for 1024x768,
and
one for 800x600). It will 'bloat' your code but makes it so much
easier in
the long run. If exec size is a problem consider supplying two
products.

Like Karl pointed out, it can be a real PTIA to adjust for all cases.
(Throw
large and small fonts, and a few custom controls, into the mix and it
gets
ugly in a hurry.) It is far easier to just change your development
box's
resolution - open the forms and re-design them.

Just a suggestion.

-ralph












.

Quantcast