Resize MSAccess Forms

[WGHayes]

Hi,

We are currently in the process of trialling various Resize/Rescale
controls/code and have come across a number of issues with this approach.
We have an MS Access 2000 application designed at 800x600 screen resolution
and are wanting to use a resize control to allow forms to resize to the
available screen resolution, or, operate on any form size between 800x600
and the maximum screen resolution.

Controls/code trialled include:-
- Code from 'Access 2000 Developers Handbook'
- A2K Resize Control MDE (apparently developed from code in handbook but
seems to work better)
- Shrinker Stretcher
- FMS Resize Control

Our approach has been that we DO NOT want to use Scaling, only resizing, and
we only want this to work on specific controls. It seems from the controls
above that the only control/code that will allow us to selectively choose
controls to 'resize' is the 'Access 2000 Developers Handbook' and A2K Resize
control.

The 'primary' controls on our forms that we want to resize are:-

- TAB Controls
- Sub Forms

NOTE:- Specifically, but allowing SUB forms to expand users are able to see
more data across a 'datasheet' view. This is our primary objective. It
also happens that these sub-forms may be on TAB controls therefore both the
TAB and SUB FORM must be able to be resized.

What we are finding is that with the 'Access 2000 Developers Handbook' code
and A2K Resize control is that where there are TAB controls on the form
(which are set to resize) then when a form is resized DOWN to less than 20%
of it's original size then these TAB controls move over existing controls
(which is correct) but do not then move back to there correct position when
the form is then resized UP (i.e. the TOP position of the TAB control is NOT
as it was designed - it has moved). Whilst this problem can be avoided by
setting MIN width and height properties this is not ideally how we would
want to use the control (i.e. impacts on form TILING).

Questions we have:-

- Is anyone else using the 'Access 2000 Developers Handbook' code, OR, the
A2K Resize control that have found similar issues? Where these issues
resolved and/or what work around was used?

- What other Resize controls are available for Access 2000 that I have not
already mentioned?

Any comments regarding our approach to 'resizing' are also welcome.

Thanks,
Wayne.

 

[TC]

Four comments, for what they are worth.

(1) It is very difficult to get this to work *perfectly* over every
possible resizing action. This is because there are no published
details on *precisely* how the individual controls are sized and
positioned by Access. A 1 or 2 pixel fault in the code, will usually
have no obvious affect under normal circumstances, but it can have a
big affect if you take drastic actions such as, resizing the form down
to 20% & then back up again! In particular, option groups & tab cotrols
are very hard to handle properly. (I know; I've done it. And it still
doesn't work quite properly, despite a lot of time & effort.) So IMHO
it's just not realistic to expect pixel-perfect operation for every
possible resizing action. I don't believe that any solution will be
able to achieve that.

(2) It's easy to resize textboxes, listboxes & combo boxes and maintain
their aspect ratios. But the text within them is a seperate matter!
You'll often find that the box resizes correctly, but the text within
it is resized 1 or more point sizes too big, or too small. For that
reason, I have seriously considered doing the following: Have a resize
function in the code. But also, have some "standard" resize information
in an external configuration file, or whatever. When the form is
resized, if it is resized to a value defined in the config data, get
the text font sizes from there; otherwise, calculate them & hope for
the best. By that means, you'd get a known-good result in all the cases
where you bothered to save the config data. And in all other cases,
you'd get whatever result the resize code would have given you "by
default". More work - for a better result.

(3) Make sure all your fonts are TrueType fonts. TT fonts can be reized
arbitrarily. This helps, but does not *fix*, the scaling problem noted
in (2). Non-TT fonts will generally be terrible, because they don't
scale arbitrarily.

(4) IIRC, ShrinkerStretcher lets you selectively choose controls by
putting various values into their Tag properties. If not, and you have
purchased the source, you could easily fix it to do that.

Finally: you'd do the Access community a useful service, if you were
willing to write a detaled comparative review of all the products you
eventuall test. The resizing problem is quite a hassle for everyone,
and it would be great to have more details on the various solutions
available. If you're willing to do that, and you do not have your own
website, I'd be happy to host that information for you, on my site,
with full attribution to you.

HTH,
TC (MVP Access)
http://tc2.atspace.com

 

[david epsom dot com dot au]

How many subforms and tabs do you have on a form? If
all you want to do is resize the tab controls and
subform controls, consider re-designing your forms
instead of using the more general published solutions.

For example, all of our standard datasheet subform
shells contain the following code in the resize event:


If (Me.InsideWidth > 0) And _
(Me.InsideHeight > Me.Section(Access.acHeader).Height) _
Then
Me.sbfData.Width = Me.InsideWidth
Me.sbfData.Height = Me.InsideHeight - Me.Section(Access.acHeader).Height
Me.lblHeading.Width = Me.InsideWidth
End If

To get that to work, we moved all the controls to
the header, and put the subform in the detail section.
In those forms, there is only one subform control,
and the subforms are swapped into it.

We do have more complex forms, but again, the forms
are designed to be resized - not designed for a single
size, then with resizing code tacked on.

Incidentally, let me say :~) that I am very proud of
those 5 lines given above, and that the form design
was not a trivial exercise.

(david)