Ability to set CanShrink and/or CanGrow in Report sections

[NiccoMlt]

Hi,

I cannot understand how to programmatically enable dynamic shrinking and/or growing of sections on programmatically generated report objects.

In particular, from documentation it seems like that at least CanShrink property should be provided, but I cannot find it from code. What am I missing?

Alternatively, is there a way to make PageHeaderSection, PageFooterSection and DetailSection dynamically resize their height accordingly to the height of the visible items inside them?

Thanks in advance

[Neli]

Hi NiccoMlt,

Basically, the detail section will grow based on the records in the datasource. The page header and footer can not grow or shrink and therefore can not accommodate for content expanding outside its section area.  For example, if a textbox has a longer string than it can fit, and the CanGrow property is set to True, the textbox will increase in size to make room for the entire string. Then, if the textbox expands below the edges of the section, either the string will be cut off, or disappear entirely. You can also check the Report Structure article and TextBox Disappears KB article.

Please, consider sending us the problematic report, so we can inspect it locally.

Regards,
Neli
Progress Telerik

[NiccoMlt]

Hi Neli, thank you for your answer.

I understand. I agree with you that the problem is related to PageHeader and PageFooter not being able to grow or shrink, differently from what DetailSection can do; in particular TextBox Disappears KB article describes what I am experiencing accurately.

Also, what you linked me probably contains the solution to my problem: "The Height of the section may be changed runtime with Bindings. Our recommendation is to set the default height of the section to the maximal expected one. Then, you may reduce the height of each Page section with a proper Binding.". I will try and report you back.

If needed, I will certainly send you a sample report to check up, but as I answered you here it requires some work, because the converter that I implemented generates reports that heavily depend on user-defined functions, and also the data source is only built and attached at runtime from a sequence of externally-generated data, so it needs to be adapted.

Thank you very much for your help, I'm sorry that I missed those parts when searching in the documentation.

[Marcel]

I came here after searching your documentation for a solution because reducing the header height at runtime with a binding did not work. Our challenge is we have a header for the first page only which contains an image, and a header for the remaining pages which contains text with the name of the addressee, date, and page x of y. Both the text box and the picture box are the same height so if we put them on top of each other and flip the visibility, that gets the result we need. However this is awkward at design time and I wanted to position one below the other in the header panel, turning one invisible at runtime and at the same time shrinking the height of the entire header panel by half with its own binding. This did NOT work and the unwanted header, while now invisible, still occupies space as the header keeps its design-time height. Any thoughts?

[Marcel]

Also may I ask why you have enabled Can Grow/Can Shrink for the details of the report but not the header and footer? Surely there are many use cases like ours where it would be handy. And it's only coincidence that our first page and subsequent page headers are the same height.

[Momchil]

Hello Marcel,

I see that you have opened a personal support ticket with the same questions and I have provided a reply to it. I am also copying my message from the ticket in case anyone else encounters the same issue but if you need additional assistance I would suggest we continue our communication in the support ticket.

 

Shrinking the page header with a binding does not work.

This is not expected because, as long as the design-time height is greater than the height you are binding to, the size of the header should change accordingly.

Perhaps the binding expression does not return a valid size, i.e. a string in the format "{number}{unit of measurement}".

Why are the CanGrow/CanShrink options enabled for other sections but not the page sections?

This is done to ensure that the available height on the page after rendering the Page Header and Footer sections will be positive. Otherwise, there will be no way to place detailed content on the page. See the third point in the Page Header section of the Report Structure article for more information. 

How to change the height of the page header to different sizes for each page rather than just half?

As long as the design-time height is set to the maximum expected height, you should be able to use a combination of the built-in Conditional and Page functions to get the desired result. For example:

= Switch(PageNumber, 1, "1cm", 2, "2cm", 3, "3cm")

[Neli]

Hello NiccoMlt,

I am glad that we found the reason for the behavior. Please, do not hesitate to contact us again if you need further asssistance.

Regards,
Neli
Progress Telerik

[NiccoMlt]

Hi Neli, thanks for your time.

I tried binding the Height property with an user-defined expression that resolves the actual height, but it seems not to be applied.

The expression is declared like so:

[Function(Category = "Telerik functions for ParSt reports", Namespace = "PARST.Telerik", Description = "Compute the actual height of a section")]
public static Unit ComputeHeight(Telerik.Reporting.ReportSectionBase thisItem) =>
    thisItem.ResolveActualHeight();

And it uses the following extension method:

internal static Unit ResolveActualHeight(this ReportItemBase item)
{
    var childrenHeight = item
        .Items
        .Where(child => child != item)
        .Select(ResolveActualHeight)
        .Aggregate(Unit.Zero, Unit.Add);

    var currentHeight = item switch
    {
        ReportItem { Height: var height } => height,
        ReportSectionBase { Height: var height } => height,
        Report { PageSettings: { PaperSize: { Height: var height } } } => height,
         _ => throw new ArgumentOutOfRangeException(nameof(item), $"Unexpected type {item.GetType()}: {item}"),
    };

        return Unit.Min(currentHeight, childrenHeight);
}

I adapted my report converter to generate TRDX reports which embed the data source as JSON array of objects and it should not reference user-defined expressions besides the above.

I'd like to leave a sample for you to check, but the forum doesn't let me attach a TRDX file, so I put it in a GitHub Gist:

https://gist.github.com/NiccoMlt/0a2d8c7e76fc4b90fac6aa3a91f1d897

The content may be messed up (the converter is not fully functional yet), please focus only on the HEAD and FOOT sections.

What do you think I am doing wrong?

Thank you in advance.

[NiccoMlt]

Hi Neli,

this weekend I did some deep search in this forum about growing/shrinking sections.

I found out that Group Sections may be a solution to generate headers and footers with the ability to shrink according to their content, so I updated my converter to generate a report composed by a GroupHeaderSection, a DetailSection and a GroupFooterSection, all of them with the CanShrink property enabled, and a (maximum) Height calculated according to the total height of the items put inside each section. I also disabled the binding with the Height property.

The problem is, the CanShrink property seems not to be working as I expected: neither the GroupSections nor the PageSection shrink when rendered, at least in the ReportDesigner preview.

I uploaded the new TRDX here for you to check: https://gist.github.com/NiccoMlt/042785d8490be7b176507be9af60bfe8

What do you think?

Thank you again in advance

[Neli]

Hi NiccoMlt,

Thank you for the provided report. 

Basically, the CanShrink functionality will work when the Visible property of an item in the section is set to False. For example, if you set the Visible property of a textbox, then the height of the group header section will be decreased.

I would recommend decreasing the height of the group header section which will be increased if more space is required.

Regards,
Neli
Progress Telerik

[NiccoMlt]

Ok thanks, good to know that the behavior of CanShrink is not what I understood.

The problem is, even setting the height of the rows to 1pica (which is my expected minimum, there is no need to go lower) and thus relying on the capability to grow of the sections, the sections not always grow enough.

See for example the attached screenshot, which is the rendering of the report at the following GitHub Gist: https://gist.github.com/NiccoMlt/4e80b9b8d6c08d60555d27d7107bddc0

The head of the page (which is a GroupHeaderSection) overlaps with the first line of the body (which is a DetailSection).

Is it a bug or am I configuring something in a wrong way?

[Neli]

Hi  NiccoMlt,

Thank you for the provided report.

Please, test to increase the Group Footer Section's until the textboxes appear. You can check the updated report definition that demonstrates the approach. Let me know if the outcome satisfies your needs.

Regards,
Neli
Progress Telerik

[NiccoMlt]

Hi Neli, thank you for your answer, but it doesn't help.

The report I attached in the previous message is autogenerated by converting an old one from a proprietary solution, and I need the generated Telerik report to support headers and footers that may change size from page to page (and thus I can't compute the size at conversion time).

I read that it could be a problem for Page Sections, but Group Sections (like the ones I'm using) should be able to grow as needed, am I right?

[Neli]

Hi NiccoMlt,

Thank you for the additional information.

I inspected the report again and I noticed that in the group header section, there are a few items, each with a height of 1pc. One of the options that you can test is to set the height of the group header section to be 7pc. The other option which is available since 15.0.21.120 is to use a page header section and set its height through a Binding.

Let us know if you have any questions.

Regards,
Neli
Progress Telerik

[NiccoMlt]

Hi Neli,

[quote]Neli said:
Hi NiccoMlt,
Thank you for the additional information.
I inspected the report again and I noticed that in the group header section, there are a few items, each with a height of 1pc. One of the options that you can test is to set the height of the group header section to be 7pc
[/quote]

Yes, the header can be set with an height of 6pc to accomodate everything, but it is not a solution that I can adopt in my converter: the legacy report format I'm converting from supports an IF-ELSE conditional block construct that allows the report designer to define headers/footers that can accomodate a variable number of rows according to a condition over printing data that is evaluated at print time.

[quote]Neli said:

The other option which is available since 15.0.21.120 is to use a page header section and set its height through a Binding.

[/quote]

This was your first suggestion, that I already tryied, but as I said in a previous post, I didn't managed to get it working. Was the binding logic wrong in some way?

Thank you very much for your time.

[Neli]

Hi Nicco,

Is it possible to send us the non-working version of the report in which you used the page header and binding for the height, so we can test it locally?

Regards,
Neli
Progress Telerik

[NiccoMlt]

Hi Neli,

the company my University is collaborating with opened a support ticket about this problem. The bug was acknowledged and a bug report was opened: https://feedback.telerik.com/reporting/1512290-height-not-correctly-calculated-resulting-in-overlapping-elements-when-docking-top-and-panels-are-used.

As a workaround, because precomputing the height of the whole section was not acceptable, I'm currently precomputing only the height of the panels inside the section, allowing the parent section to grow correctly.

Thanks again for your support and best regards.

[Neli]

Hi NiccoMlt,

Thank you for the provided information. I set the status of the bug to Unplanned which basically means that it is approved but we don't know when it will be fixed. Once there is an update, you will receive a notification.

Regards,
Neli
Progress Telerik