StretchMode causes long delays

DMIUser

In FastReports VCL 4.8.7, if I set the StretchMode on any TfrxMemoView to anything but smDontStretch, the report will take significantly longer to finish printing. If I just set that same field to smDontStretch, it will finish very quickly with the correct data, just not stretched. The time difference is 1-2 seconds for smDontStretch and approximately 30 seconds for smActualHeight or smMaxHeight. Is there anyway to speed up this process?

gordk

try latest build and see if you still have the problem.

DMIUser

I just tried with version 4.8.21 and the same problem occurs.

gordk

i cant reproduce it here. Suggest you go your dl page and take out a support ticket.

DMIUser

I just submitted a support ticket but for the sake of this thread, here are the steps to reproduce this:

Run the Main Demo and select "Basic Reports" -> "Simple list" -> Design.

Make the following modifications:
- Changed the Band.Stretched = True
- Made the Master data band larger
- Added a TfrxMemoView to the bottom of the band and set its StretchMode to smActualHeight. Shrink the height so it is smaller than the text display in there.
- Copied and pasted the other controls a few times to make more rows of controls to simulate a busy report.

Save and close the designer. Now hit "Preview" and the report will take a long time to process.

gordk

you may have created the situation by moving all other memos around.
within a band memos are processed in the order of creation

DMIUser

The reproduction steps above are just what I originally did to reproduce the issue. You can get it to occur by first creating all the extra memos and then finally creating the one stretched memo. So creation order is not the entire issue here.

DMIUser

gordk wrote: »

you may have created the situation by moving all other memos around.
within a band memos are processed in the order of creation

I took your suggestion and tested it out. I reordered all of the controls in the XML based on their position. So now the last control being created is the one being stretched. The delay was pretty much the same. So creation order is not the issue based on this test. As of right now, I have not received any reply from the Help Desk Ticket that I posted over a week ago. Not even a confirmation "We'll look into it" message. Our customers are beginning to get upset over this issue because they can not create a report that has large amounts of data in a TfrxMemoView.