Activate Groups at runtime...?
Hi out there,
I have a report that contains two groups for "Field A" and "Field B". Now I
want the user to be able to select
- No Grouping
- Goup Field A
- Group Field B
- Group Fiel A then Field B
- Group Field B then Field A
It works when selecting "A then B" or "B then A" (as I change the sorting
order of my data) - but when selecting only one group, the reports keep
showing both groups.
Q: Is there a way to turn off grouping for a specific group at runtime?
Kind regards,
Mark Meyer
I have a report that contains two groups for "Field A" and "Field B". Now I
want the user to be able to select
- No Grouping
- Goup Field A
- Group Field B
- Group Fiel A then Field B
- Group Field B then Field A
It works when selecting "A then B" or "B then A" (as I change the sorting
order of my data) - but when selecting only one group, the reports keep
showing both groups.
Q: Is there a way to turn off grouping for a specific group at runtime?
Kind regards,
Mark Meyer
This discussion has been closed.
Comments
Unfortunately there is no way to "deactivate" a group in a report. If you
would like to remove a group, you will need to remove it completely from the
report. You can use the TppReport.Groups TList property to access any group
you need and free it from there. Be sure to also set the group's Report
property to nil when you do this.
--
Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com
by a user selection. Here is the code I use:
If subtot1='Y' Then //subtot1 indicates if group1 should be used
begin
Group1.BreakType:=bt; //bt a TppBreakType and is always=btDataField
Group1.BreakName:=sname; //sname is name of field to break on
GroupHeaderBand1.Visible:=True;
GroupFooterBand1.Visible:=True;
end
Else
begin
GroupHeaderBand1.Visible:=False;
GroupFooterBand1.Visible:=False;
end;
HTH
Kevin
unfortunately that doesn't work:
ppGroupKArt.BreakType:=btDataField;
ppGroupKArt.BreakName:='Bezeichnung';
KArt_Header.Visible:=False;
First of all, "btDataField" is "unknown" - though corresponding to the
help file it should be declared in ppclass - that makes my app being
unable to compile.
Sencond: How did you set your GroupHeaders property at design time?
I guess sname is depending on your users decision, which field to group
by?
In my case, I have "two level grouping" of an account, based on either
one or two aspects: "Month" and "Kind of payment"
This makes it necessary to change the sorting order of the data. I'm
doing this creating different "ORDER BY"-clauses for my TQuery.
But ReportBuilder still keeps grouping "Month" first - even if he does
not show the group header and sum. That results in having several
group-headers for the same kind:
(Head January - Visible:=False)
Group Type 1
Group Type 2
Group Type 3
(Sum January - Visible:=False)
(Head February - Visible.....)
Group Type 1
...
I'll try deleting the goups at Runtime like Nico suggested. Well - dear
developers - may I recommend to add some funtionality like an
"Active"-property to each group?
Kind regards,
Mark Meyer
I simply can't believe that something so simple like "user defined
grouping" should result in creating 5 different reports - what would
that be for a reporting tool?
Hi,
thanks - that worked nearly perfect. Unfortunately there doesn't seem
to be a possibility to change the order of my groups either. Even if I
sort "ORDER BY Date, Type" I get a report like
Type A
June 03
Type B
June 03
Type A
July 03
instead of
June 03
Type A
Type B
July 03
Type A
So in this case it seems to be necessary to re-order the groups - if I
do this at design time, it works fine. But
AGroup:=Report.Groups[0];
Report.Groups[0]:=Report.Groups[1];
Report.Groups[1]:=AGroup;
won't work as Report.Groups is ReadOnly...
So - how can I change the order at runtime in order to make this
working properly?
Kind regards
Mark Meyer
In versions 6 & 7 btDataField is defined in ppTypes.
I have the 3 levels of group headers and footers set up at design time.
The visible property of the group header is True (but the header is
empty and has a height of zero) and the visible property of the group
footer is False.
Yes
I also use ORDER BY to sort the result by the grouping fields that the
user chooses.
Make sure you are assigning the correct field to the correct group. If
my design is like this
Group A Header
Group B Header
Group C Header
Detail
Group C Footer
Group B Footer
Group A Footer
and the user chooses to group on Month, PaymentType then I put ORDER BY
Month, PaymentType in the SQL and in the report I set
GroupA.BreakName:=Month;
GroupA.{Headers and Footers}.Visible = true
GroupB.BreakName:=PaymentType;
GroupB.{Headers and Footers}.Visible = true
GroupC.{Headers and Footers}.Visible = false
Also be careful because the groups can have confusing names if you use
the default RB names. For example in my report design
Groups[0].Name='Group1', Groups[1].Name='Group3', and
Groups[2].Name='Group2'. It looks like you are renaming your groups
though so this may not be a problem for you.
Kevin
Try using the TppReport.MoveGroup procedure to change the order of the
Groups TList. For more information, search TppReport.MoveGroup in the
ReportBuilder help.
--
Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com
thanks a lot - I see you're having three groups and instead of changing
the order you're changing the BreakName - that's a bit different like I
thought - but it took me a while to realise that RB prints it's groups
according to the order given within the groups-array. So if groups[1]
has to be printed again before groups[1] was, RB simply prints #1, too.
I thought it would print a group every time BreakName changes no matter
what it's position is.
When I realised that behaviour, I tried to change the group-order
(thanks to Nico who pointed out the right way to do this) - your way
seems to be quite effective, too - and you don't have to "kill" some
groups which makes me having to re-create the whole report-form or
create a group manually again in case it's needed later on.
I'll try this with the next report I have to migrate from QuickReport
to RB - that's some kind of stupid work: You have hours of time to
spend just to make your app do the same as it did before - at least
that's what my customers think ;-)
Mark