C1FlexGrid: improved "AutoSizeRows" for merged ranges

Posted by: wknauf on 3 November 2020, 7:52 pm EST

  • Posted 3 November 2020, 7:52 pm EST

    Hi,

    I noticed that "AutoSizeRows" might result in "not so nice looking" results if merged ranges with long texts are involved.
    Attached is a sample which has a cell merged over three rows with very long text.

    When calling "AutoSizeRows", all rows of this range get the same height, which looks bad for rows 1 and 2 of the range, as the content of the other cols of those rows is smaller, and thus the rows could have a smaller height:


    So I tried to improve it: all rows get only the required height, and the last row of each merged range gets the remaining height and will be much larger. Result is this:


    But this is very clumsy and inperformant code, as I make a lot of calls to "AutoSizeRows" with "AutoSizeFlags.IgnoreMerged". And this code will fail if there are overlapping merged ranges which start in different rows. I think I could fix this problem if there was any method in C1FlexGrid to calculate the height of a cell range (or a merged range). Could you add this? This code probably exists as part of "AutoSizeRows", so hopefully you could extract part of this code and make it public API.

    Bonus problem: is it a feature or a bug that "AutoSizeRows" for a custom merged range will only work if all cells of the merged range contain the same text and the same "word wrap" style? I think the top left cell of a merged range defines rendered content, so it should also define the "AutoSizeRow" result.

    FlexAutoSizeRow.zip

    Best regards

    Wolfgang
  • Replied 4 November 2020, 10:54 pm EST

    Hi Wolfgang,

    We are discussing this with the developers and will get back to the updates soon.
    [Internal Tracking ID: 23851]

    Regards,
    Prabhat Sharma.
  • Replied 4 November 2020, 11:49 pm EST

    Hi Prabhat,

    I had an idea on how to fix the issue with overlapping ranges in my own sample: instead of calling "AutoSizeRows" for the whole grid to get the height of all merged ranges, I could call call "AutoSizeRows (toprow, leftcol, bottomrow, rightcol)" for each merged range and thus get the height for just this range. This should resolve the problem with ranges whoses rows overlap (though they are in different cols).

    But the main issue is still "how can I measure the ranges without having to use AutoSizeRows?".

    Best regards

    Wolfgang
  • Replied 5 November 2020, 1:04 pm EST

    Hi Wolfgang,

    Thank you for the additional information.
    We will let you know once we get an update from the developer.

    Regards,
    Prabhat
  • Replied 10 February 2021, 10:01 pm EST

    Hi,

    any update from the developers? Are there plans to implement this?

    Best regards

    Wolfgang
  • Replied 11 February 2021, 1:36 pm EST

    Hello,

    We are getting in touch with the developers for the updates and will let you know soon.

    Regards,
    Prabhat Sharma.
  • Replied 8 March 2021, 12:33 am EST

    Hi Prabhat,

    any feedback from the developers?

    Best regards

    Wolfgang
  • Replied 9 March 2021, 10:41 pm EST

    Hello,

    Our developers are working on this issue and we will let you know the updates soon.
    Regards,
    Prabhat Sharma.
  • Replied 27 April 2021, 9:27 pm EST

    Hi,


    The developers have shared the workaround sample "Workaround.zip". They implemented another way to do what you want. Its clearer, has more performance, and also handled overlapping merged ranges correctly.

    For the Bonus problem: the developers need some screenshots with the explanation of the issue.

    Regards,
    Prabhat Sharma.
    Workaround.zip
  • Replied 29 April 2021, 5:25 pm EST

    Hi Pabhat,

    this sounds promising, but the "Workaround" sample has one bug: the cell in the screenshot is clipped:


    Also, I fear that using your workaround suggestion causes performance issues, because AutoSizeRows is called twice for merged ranges. And in our application, the grid where I would like to see this improved "AutoSize" logic, has merged ranges for most rows and it will contain a lot of rows. Here, performance is critical. So I hope that you can add it to C1FlexGrid, where you probably have a better control for performance and could measure cell texts only once.

    Also, the workaround currently only works for "AllowMergingEnum.Custom", but in our real grid, we use "AllowMergingFixed = Free". OK, it would be possible to change our grid.


    About the bonus problem: attached sample shows it: I removed most of the filling code, so that only one large merged range remains. Click the "AutoSizeRows" button => text will be clipped.
    It works if I set text and style with "WordWrap" to all cells of the range.
    BonusProblem.zip
    Screenshot:


    Best regards

    Wolfgang
  • Replied 2 May 2021, 8:54 pm EST

    Hello Wolfgang,

    Thank you for the detailed explanation, we have forwarded your comments to the development team and will let you know as soon as we get the update from their end.

    Regards,
    Prabhat Sharma.
  • Replied 5 May 2021, 12:09 am EST

    Hi,

    Please find the developer's comment on the issue:

    >> The "Workaround" sample has one bug: the cell in the screenshot is clipped. issue1.png
    Text and style for c1FlexGrid1[4, 1] was not set. I didn't set it by accident.

    this.c1FlexGrid1[4, 1] = shortmerged;
    this.c1FlexGrid1.SetCellStyle(4,1, styleWrap);



    will fix the bug. And this is just an example of a bonus problem. And about it: the style and text are involved in the calculation of the height of the range, even for merged cells. So this is not a bug, this is how it works now.

    About performance: I think that this is a fairly productive solution. Since the second autosize call only applies to a small merged range. But since it applies to all ranges, in the worst case, the performance will be 2 times lower than calling the AutoSizeRows method (for all cells) 1 time. I don't think that what you need, can be done in the one loop with the current behavior.

    You can always work on performance and gradually improve it, but you need to do this after the desired behavior is achieved.

    We can not embed a behavior that you need in the grid. But we can add some public API that can help you. You wrote that calculating the height of the range can help you. Is this still relevant?

    Regards,
    Prabhat Sharma.
  • Replied 5 May 2021, 5:03 pm EST

    prabhat.sharma said:

    We can not embed a behavior that you need in the grid. But we can add some public API that can help you. You wrote that calculating the height of the range can help you. Is this still relevant?


    Yes, this would be very helpful. Probably, a methode "GetCellSize" or "MeasureCellSize" for a single cell would be sufficient, as I would have to call this only for the top left cell of each merged range.
    Thus, I could even avoid the duplicate size calculation if I do the "AutoSize" calculation for the whole grid myself.

    I am looking forward to the new method ;-)


    The "bonus problem" is OK for me, though I think it is confusing to require the full merged range to have the same content.

    Best regards

    Wolfgang
  • Replied 5 May 2021, 10:19 pm EST

    Hello Wolfgang,

    Thank you for your comments, we have forwarded your comments to the development team and will let you know as soon as we get the update from their end.

    Regards,
    Prabhat Sharma.
Need extra support?

Upgrade your support plan and get personal unlimited phone support with our customer engagement team

Learn More

Forum Channels