New Page 1

This sample db demonstrates bottom alignment of text in various text boxes in an access report. It involves dynamic adjustment of top margins in such a manner that for each record, grown height of each text box in the detail section matches that of the tallest one, at the same time ensuring uniform bottom alignment.

Dynamic height (grown height) of a control can be captured only in the print event. However, direct manipulation of control's size or position is not allowed in this event. For consistent results, necessary adjustment in top margin should be made in the format event. In the sample db, this objective is achieved by two stage opening of report. In the first stage, grown heights of controls, as exposed during print event are stored in a temporary table (T_Temp). These values are then used to
adjust the heights and top margins of controls during second stage opening of report.

    Two styles of report with bottom alignment of text are covered:
    (a) Simple - Without grid lines.
    (b) With grid lines - Spreadsheet style

Except for the name of row counter text box, generic code is used so as to automatically suit any number and nomenclature of controls.

While drawing vertical grid lines in style (b) above, the locations are set programmatically in such a manner as to fall mid-way between adjacent controls.

For optimum effect, it has been ensured that top margin of first control displaying row numbers is dynamically kept identical to that of next adjoining control.

The following alternatives stand rejected:

(a) If top margins were to be manipulated within print event itself, corresponding effect on grown height would have been out of sync, getting manifested only upon firing of next print event.
(b) Padding up the shorter control with suitable number of vbcrlf's in print event, so as to match its grown height with the taller one is also found to work. The rows of text in each control are calculated by taking into account the TextWidth property as compared to control's width. However, it runs into a snag. The wrapped text does not leave uniform side margins (visa vis the control's borders) on each line. This detracts from precise calculation of the number of rows occupied by the contents of different controls. As such, if this alternative were to be adopted, the results might not always measure up to the desired level of perfection.

Note:
This update overcomes the need to navigate through each page of report so as to fetch grown heights of controls as revealed in print event, thereby eliminating dependence upon either SendKeys method or Stephen Leban's API based page turner function. It is understood that SendKeys stands broken in Windows 7 while Leban's function fails to work in Access 2010. Instead, Setting report's MoveLayout property to false in first stage opening of report, as used in this version is found most dependable as it shrinks the report to a single page, ensuring that print events for all records get fired without having to move away from first page.