by Earl Brightup email@example.com
This six-part series describes a method of dynamically optimizing the vertical size of a Continuous Form to fit the number of rows of data to be displayed—on any screen size and resolution.
- Introduction - Continuous Forms
- Vertical Sizing by Hand Adjustment
- Vertical Sizing by Calculations
- Vertical Positioning (this post)
- Sample Access Database Demonstration
- Adapting Dynamic Sizing and Positioning Code to Your Continuous Form
You can find a sample with complete documentation here: http://www.rogersaccesslibrary.com/forum/topic600_post618.html
IV. Vertical Positioning
After determining the number of rows of data to be displayed (maximum or otherwise) and specifying the vertical size of the Continuous Form, consideration can be given to the vertical positioning of the form within the Access window. Horizontal positioning is not a consideration since it does not affect vertical sizing or positioning.
The specifics of satisfactory vertical positioning are pretty much individual preferences. Although the metrics from the form make it possible to vertically center the form within the Access window, vertical centering (particularly with small forms) does not seem to lend itself to comfortable viewing by the user. Positioning in the upper part of the Access window is generally preferable to positioning it lower.
The vertical positioning logic used in the sample forms favors the upper part of the window (30% of unused Access window space above the form), but can easily be changed. This amount was determined after testing, but is not based on any scientific value. Perhaps the suggestion here will spur your thinking toward something better.
The simple vertical positioning logic used in the sample forms is spelled out here in pseudo code:
Const sglPctSpAboveForm as Single = 0.30
'Since the form has been resized, get the form's current 'measurements in Twips, including the overall FormHeight.
Call mfi.GetSize ...
' Position form vertically in the Access window.
DoCmd.MoveSize , (WindowHeight - FormHeight) * sglPctSpAboveForm
The MoveSize calculation results in the integer number of twips for positioning the top of the form down from the top of the Access window.
A suggestion on moving the form:
There is probably something the author is not familiar with, but it seems that Windows 7 (don't know about XP) complains about moving a form unless it already contains records. You might want to try something different, but it appears to be necessary to use a "Requery" statement somewhere prior to using the MoveSize statement.
Next time: Sample Access Database Demonstration