Show Field for "Last" Record in Group Only

  • Thread starter Thread starter Simon Shutter
  • Start date Start date
S

Simon Shutter

Duane et al,

Great tip - is there an equivalent method for putting a footer field
adjacent to the last record in the details section?

Tx
 
You could try
-Create a text box in the detail section
Name: txtDetCount
Control Source: =1
Running Sum: Over Group
Visible: No
-Add a text box to the Group Header
Name: txtHdrCount
Control Source: = Count(*)
-Add code to the On Format event of the Detail Section:
Me.MoveLayout = Me.txtDetCount <> Me.txtHdrCount

This is just a WAG that might need to be played with to get it to work.
 
Duane, works like a charm if you put txtHdrCount in the Group Footer not the
Group Header. The row counter control (txtDetCount) is a great tip also.
Thanks again for your insight.
 
Now, that is really interesting. I don't know when the
ability to refer to a group footer control's value in the
group header or detail, but it works in both A97 and AXP so
it has been around for quite awhile.

Now, I'm wondering what other "out of order" calculations
can be done???
 
Marshall Barton said:
Now, that is really interesting. I don't know when the
ability to refer to a group footer control's value in the
group header or detail, but it works in both A97 and AXP so
it has been around for quite awhile.

Now, I'm wondering what other "out of order" calculations
can be done???
Click to expand...

I've always assumed that similar to the use of [Pages] that such structure
simply forces the report or section to be processed twice (or retreat) so that
values that would superficially seem to be unavailable because "they haven't
been calculated yet" are in fact available in those prior sections.
 
"Marshall Barton" wrote
Rick said:
I've always assumed that similar to the use of [Pages] that such structure
simply forces the report or section to be processed twice (or retreat) so that
values that would superficially seem to be unavailable because "they haven't
been calculated yet" are in fact available in those prior sections.
Click to expand...


That was my first thought too, Rick. So I ran a test with a
Debug.Print in each event procedure and there was NO
"double" processing. It's as if there's an evaluation tree
for the whole report and the calculations are done as
early(?) as possible.

This kind of "early" calculation seems to befuddle
RunningSum calculations. The "out of order" value of a
group footer text box that refers to a detail running sum
text box is the initial value. Furthermore, the header
reference to the group footer total seems to "lock" the
group footer value so that it does not reflect the final
value of the running sum text box. Wow, is that a confusing
statement or what. Let's try an example:

Group Header:
=txtGrpCount 1
Detail:
txtRunCount =1 (runsum) 1,2,3

Group Footer (with the group header reference)
txtGrpCount =txtRunCount 1
Group Footer (without group header reference)
txtGrpCount =txtRunCount 3
 
Marshall said:
"Marshall Barton" wrote
Click to expand...
Rick said:
I've always assumed that similar to the use of [Pages] that such
structure simply forces the report or section to be processed twice
(or retreat) so that values that would superficially seem to be
unavailable because "they haven't been calculated yet" are in fact
available in those prior sections.
Click to expand...


That was my first thought too, Rick. So I ran a test with a
Debug.Print in each event procedure and there was NO
"double" processing. It's as if there's an evaluation tree
for the whole report and the calculations are done as
early(?) as possible.

This kind of "early" calculation seems to befuddle
RunningSum calculations. The "out of order" value of a
group footer text box that refers to a detail running sum
text box is the initial value. Furthermore, the header
reference to the group footer total seems to "lock" the
group footer value so that it does not reflect the final
value of the running sum text box. Wow, is that a confusing
statement or what. Let's try an example:

Group Header:
=txtGrpCount 1
Detail:
txtRunCount =1 (runsum) 1,2,3

Group Footer (with the group header reference)
txtGrpCount =txtRunCount 1
Group Footer (without group header reference)
txtGrpCount =txtRunCount 3
Click to expand...

Yeah, my testing agrees with yours in that using =[SomeOtherControl] as a
ControlSource does not appear to work correctly. What does appear to work is
having a running sum control and then in the group footer's format event setting
the value of a control in the footer. Then a control in the header with a
ControlSource of =[NameOf ControlInFooter] properly displays the same value as
the control in the footer.
 
"Marshall Barton" wrote
Now, that is really interesting. I don't know when the
ability to refer to a group footer control's value in the
group header or detail, but it works in both A97 and AXP so
it has been around for quite awhile.

Now, I'm wondering what other "out of order" calculations
can be done???
Click to expand...
Rick said:
I've always assumed that similar to the use of [Pages] that such
structure simply forces the report or section to be processed twice
(or retreat) so that values that would superficially seem to be
unavailable because "they haven't been calculated yet" are in fact
available in those prior sections.
Click to expand...
Click to expand...
Marshall said:
That was my first thought too, Rick. So I ran a test with a
Debug.Print in each event procedure and there was NO
"double" processing. It's as if there's an evaluation tree
for the whole report and the calculations are done as
early(?) as possible.

This kind of "early" calculation seems to befuddle
RunningSum calculations. The "out of order" value of a
group footer text box that refers to a detail running sum
text box is the initial value. Furthermore, the header
reference to the group footer total seems to "lock" the
group footer value so that it does not reflect the final
value of the running sum text box. Wow, is that a confusing
statement or what. Let's try an example:

Group Header:
=txtGrpCount 1
Detail:
txtRunCount =1 (runsum) 1,2,3

Group Footer (with the group header reference)
txtGrpCount =txtRunCount 1
Group Footer (without group header reference)
txtGrpCount =txtRunCount 3
Click to expand...
Click to expand...
Rick said:
Yeah, my testing agrees with yours in that using =[SomeOtherControl] as a
ControlSource does not appear to work correctly. What does appear to work is
having a running sum control and then in the group footer's format event setting
the value of a control in the footer. Then a control in the header with a
ControlSource of =[NameOf ControlInFooter] properly displays the same value as
the control in the footer.
Click to expand...


Not sure what you're driving at here, Rick. I get the group
header text box value out of sync with the group footer
total in this arrangement:

Group Header A:
=txtGrpCount Null
Detail:
txtRunCount =1 (runsum) 1,2,3

Group Footer A (set via code)
txtGrpCount 3

Group Header B:
=txtGrpCount 3
Detail:
txtRunCount =1 (runsum) 1,2,3,4,5

Group Footer B (set via code)
txtGrpCount 5
 
Back
Top