![]() | |
![]() |
| | Thread Tools | Display Modes |
#1
| |||
| |||
|
#2
| |||
| |||
|
|
I have an Access 2003 report with the requirement that the height of all the controls in the detail section automatically grow or shrink to match the height of the biggest control, a CanGrow text box. *Note - this applies to each control, not just the detail section itself. |
#3
| |||
| |||
|
|
I have an Access 2003 report with the requirement that the height of all the controls in the detail section automatically grow or shrink to match the height of the biggest control, a CanGrow text box. *Note - this applies to each control, not just the detail section itself. |
#4
| |||
| |||
|
|
On Aug 31, 10:10*am, brucedodds <brucedo... (AT) comcast (DOT) net> wrote: I have an Access 2003 report with the requirement that the height of all the controls in the detail section automatically grow or shrink to match the height of the biggest control, a CanGrow text box. *Note - this applies to each control, not just the detail section itself. Is selecting all controls, changing them all to CanGrow = True not working? I think this thing is automatic for Reports (but not forms unfortunately). |
#5
| |||
| |||
|
|
I have an Access 2003 report with the requirement that the height of all the controls in the detail section automatically grow or shrink to match the height of the biggest control, a CanGrow text box. *Note - this applies to each control, not just the detail section itself. This probably would have to happen in VBA in the OnFormat event procedure. *Does anyone have a suggestion? TIA, Bruce |
#6
| |||
| |||
|
|
On Aug 31, 11:10*am, brucedodds <brucedo... (AT) comcast (DOT) net> wrote: I have an Access 2003 report with the requirement that the height of all the controls in the detail section automatically grow or shrink to match the height of the biggest control, a CanGrow text box. *Note - this applies to each control, not just the detail section itself. This probably would have to happen in VBA in the OnFormat event procedure. *Does anyone have a suggestion? TIA, Bruce Close but no cigar. I found that the size of each CanGrow control in the current Detail section is available in the OnPrint event. * In the OnFormat event it's possible to change the height of each control. * *Since OnPrint executes before OnFormat, I had to run the report twice. *In the first run, OnPrint writes the maximum control height for each line to a table. *On the second run OnFormat retrieves that value and applies it to the Height property of every control on the print line. *(I used a key value from each line as a unique identifier, but a line number would have worked as well). This succeeds beautifully in making each control as high as the tallest on the line. *Each line looks great. *The problem is that spacing between lines is irregular. CanGrow is set to True for the Detail section and its controls. * The environment is Access 2007 SP2, using an Access 2003 format database. If anyone has any advice it would be very appreciated. |
#7
| |||
| |||
|
|
On Aug 31, 5:01*pm, brucedodds <brucedo... (AT) comcast (DOT) net> wrote: On Aug 31, 11:10*am, brucedodds <brucedo... (AT) comcast (DOT) net> wrote: I have an Access 2003 report with the requirement that the height of all the controls in the detail section automatically grow or shrink to match the height of the biggest control, a CanGrow text box. *Note - this applies to each control, not just the detail section itself. This probably would have to happen in VBA in the OnFormat event procedure. *Does anyone have a suggestion? TIA, Bruce Close but no cigar. I found that the size of each CanGrow control in the current Detail section is available in the OnPrint event. * In the OnFormat event it's possible to change the height of each control. * *Since OnPrint executes before OnFormat, I had to run the report twice. *In the first run, OnPrint writes the maximum control height for each line to a table. *On the second run OnFormat retrieves that value and applies it to the Height property of every control on the print line. *(I used a key value from each line as a unique identifier, but a line number would have worked as well). This succeeds beautifully in making each control as high as the tallest on the line. *Each line looks great. *The problem is that spacing between lines is irregular. CanGrow is set to True for the Detail section and its controls. * The environment is Access 2007 SP2, using an Access 2003 format database. If anyone has any advice it would be very appreciated. Correction - OnFormat executes before OnPrint. |
#8
| |||
| |||
|
|
On 01/09/2011 11:30:54, brucedodds wrote: On Aug 31, 5:01*pm, brucedodds <brucedo... (AT) comcast (DOT) net> wrote: On Aug 31, 11:10*am, brucedodds <brucedo... (AT) comcast (DOT) net> wrote: I have an Access 2003 report with the requirement that the height of all the controls in the detail section automatically grow or shrink to match the height of the biggest control, a CanGrow text box. *Note- this applies to each control, not just the detail section itself. This probably would have to happen in VBA in the OnFormat event procedure. *Does anyone have a suggestion? TIA, Bruce Close but no cigar. I found that the size of each CanGrow control in the current Detail section is available in the OnPrint event. * In the OnFormat event it's possible to change the height of each control. * *Since OnPrint executes before OnFormat, I had to run the report twice. *In the first run, OnPrint writes the maximum control height for each line to a table. *On the second run OnFormat retrieves that value and applies it to the Height property of every control on the print line. *(I used a key value from each line as a unique identifier, but a line number would have worked as well). This succeeds beautifully in making each control as high as the tallest on the line. *Each line looks great. *The problem is that spacing between lines is irregular. CanGrow is set to True for the Detail section and its controls. * The environment is Access 2007 SP2, using an Access 2003 format database. If anyone has any advice it would be very appreciated. Correction - OnFormat executes before OnPrint. Guessing OK before we start, set all the control's Tags to 0 Scan all the controls in the report where the Tag is 0 and find the Lowest value of the .Top position of each one and the height, so giving the bottom of the control. Let's call this CtlA Then find all the controls where the .Top is between the .Top and bottom of CtlA and set the .Top = .Top(CltA), and set the Tag to +No of loops youhave gone through. So on the next scan through, the .Top will be set to the (.)Bottom of the previous row + a suitable gap. Finish the loop when there are no more tags = 0 Phil |
#9
| |||
| |||
|
|
Guessing OK before we start, set all the control's Tags to 0 Scan all the controls in the report where the Tag is 0 and find the Lowes t value of the .Top position of each one and the height, so giving the bott om of the control. Let's call this CtlA Then find all the controls where the .Top is between the .Top and bottom of CtlA and set the .Top = .Top(CltA), and set the Tag to +No of loops you have gone through. So on the next scan through, the .Top will be set to the (.)Bottom of the previous row + a suitable gap. Finish the loop when ther e are no more tags = 0 Phil Thanks, Phil. .Top apparently refers to the distance of the control from the top of the current detail section. The problem is the gaps between detail sections on the report. Good idea, though. |
#10
| |||
| |||
|
|
Guessing OK before we start, set all the control's Tags to 0 Scan all the controls in the report where the Tag is 0 and find the Lowes t value of the .Top position of each one and the height, so giving the bott om of the control. Let's call this CtlA Then find all the controls where the .Top is between the .Top and bottom of CtlA and set the .Top = .Top(CltA), and set the Tag to +No of loops you have gone through. So on the next scan through, the .Top will be set to the (.)Bottom of the previous row + a suitable gap. Finish the loop when ther e are no more tags = 0 Phil Thanks, Phil. * .Top apparently refers to the distance of the control from the top of the current detail section. *The problem is the gaps between detail sections on the report. * Good idea, though. Hi Bruce AFIK, there is only 1 Section(AcDetail) on a report. Yes, I found it took long time to grasp that measurements are from the top of a section (and from the left) I assumed the problem is with the gaps between the "rows" of controls on the Detail section. Phil- Hide quoted text - - Show quoted text - |
![]() |
| Thread Tools | |
| Display Modes | |
| |