Hi,
I got a Problem on 20110901-CStd-03-Main-Kinzig_PZ.pdf zipped in attachment. On Site 6 a subreport fills the site completely without space left. 2 pages later the report stops apruptly with wrong (multiple) grouping numbers in the corners. The report here normaly has 116 pages and not 8.
This happens quite seldom, so I decided to build a sample project (see attachment too). I can reproduce here the grouping failures beginning at the end of page 4, but not the apruptly stop of the report at this time. I think, the size of the subreport is calculated wrong. I can change the output by changing heigh of subreports detail for example:
27,3 OK
27,4 wrong grouping
27,45 unnessesary empty pages
Please try to find the bug in subreports size calculation, and inform me as soon as possible. May be you also find out, why my productive report apruptly stops in this is case.
Thanx, Martin
Bug Report
B205075
Visible to All Users
Disclaimer: The information provided on DevExpress.com and affiliated web properties (including the DevExpress Support Center) is provided "as is" without warranty of any kind. Developer Express Inc disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.
Confidential Information: Developer Express Inc does not wish to receive, will not act to procure, nor will it solicit, confidential or proprietary materials and information from you through the DevExpress Support Center or its web properties. Any and all materials or information divulged during chats, email communications, online discussions, Support Center tickets, or made available to Developer Express Inc in any manner will be deemed NOT to be confidential by Developer Express Inc. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.
Hi Martin,
Thank you for your report. We have examined this issue and come to the conclusion that the approach you have chosen is not quite correct. To fix the problem, please modify your report as follows:
Attached is a modified sample project illustrating this approach in action. Please review it and let us know whether or not the problem still persists.
Thanks,
Sergi
Hi,
I thought about your suggestion and I believe it is not possible for my report. I cannot move the pageinfo with the groupnumbers to pagefooter because the grouping numbers have a databinding (please see attachment). I also cannot move the subreports to detail because there must be first two detailreports bevor it (also seen in attachment). My solution for this was the using of two group footers, because there is no possibility to insert another detail.
I parallely tested this bug with DetailReportBand and there it happend not. So it is not understandable for me why the combined use of subreport and group footer in this case not work. I think it should.
Please can you think about my (not very easy) reportscreenshot and give me another solution!
Thanx, Martin
Hi Martin,
Thank you for your feedback. In this case, I suggest that you clear the DetailBand.PageBreak property to get the correct result. Attached is a modified sample illustrating this approach in action. Please let us know whether or not this approach meets your requirements.
Thanks,
Sergi
Hi Sergi,
for my productive report I need the pagebreaks there. For the test I changed now in the detail data rows from 36 to 71 to fill the second page completely. Now as you can see (in attachment) the report runs in trouble at page 3 again. If I set detail rows lower or higher, so that the page is not full, all works fine. But in reality I cannot influence the number of detailrows, and the report should also work.
Do you have more Ideas for me? Maybe it's still a bug…
Thanx, Martin
Hi Martin,
Thank you the clarification. I see the problem. Our developers will continue working on this problem, and we will keep you informed on any progress. Please accept our apologies for the inconvenience.
Thanks,
Sergi
Martin,
Just a follow-up: We might need to make this ticket Public, so that other customers can track its status. Please let us know if it is safe to do so.
Thanks,
Sergi
Hi,
please do not not publish the "20110901-CStd-03-Main-Kinzig_PZ.pdf" zipped in some of the attachments we send us, because of the personal data in it. The other things should be OK, to make public.
Martin
Hi Martin,
Thank you very much! I have removed the attachments you mentioned and marked this issue as Public.
Thanks,
Sergi
Hi,
some time has past, so please let me know any update you made out in this case!
Thanks, Martin
Hi Martin,
Sorry, we still do not have a complete resolution to this issue. Our developers are looking for the cause, but have not yet succeeded. We will contact you once we have any results. Thank you for your patience.
Thanks,
Sergi