none
Bug: Rich Text Box with CanGrow = True cut off in Access Report

    Question

  • It look like we've hit a bug that causes the first line of text boxes to be dropped. It happens under very specific circumstances:

    • The text box format is "Rich Text",
    • the text box's "Can Grow" property is set to "Yes",
    • the first page of the report is not included in the printout.

    Has anyone encountered this bug before and knows a workaround?

    How to reproduce the bug:

    1. Create an empty database.
    2. Create a new report in design view.
    3. Enlarge the Detail section to ensure that the report spans two pages (e.g. 31cm).
    4. At the bottom of the Detail section, add a Text box with the following properties:
      - Control Source: ="<div>row1</div><div>row2</div>"
      - Text Format: Rich Text
      - Can Grow: Yes
    5. Go to Print Preview. Note that row1 and row2 are shown on the second page.
    6. Print the report (completely). Note that row1 and row2 are being printed.
    7. Print only the second page of the report (in the Print Dialog: "Pages From: 2 To: 2").

    Here's where the fun happens:

    Expected result: row1 and row2 are being printed.
    Observed result: Only row2 is printed.

    The choice of printer does not seem to matter (it works with our HP LaserJet as well as with the MS XPS virtual printer driver). The problem can be reproduced with both Access 2007 and 2010 (including SP1).



    Wednesday, July 13, 2011 3:57 PM

Answers

  • Hi Heinzi.at,

    I can reproduce your problem on my side. I think that it is a issue, I will help you submit to the product team through the internal bug system, they will take it seriouly, then fix it.

    If there is any update about the problem, I will update this thread.

    Thank you for your understanding and wish you a nice day.

    Best Regards,


    Bruce Song [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    • Proposed as answer by Bruce Song Monday, August 01, 2011 9:35 AM
    • Marked as answer by Heinzi.at Monday, August 01, 2011 9:40 AM
    Friday, July 15, 2011 4:04 AM

All replies

  • Hi Heinzi.at,

    I can reproduce your problem on my side. I think that it is a issue, I will help you submit to the product team through the internal bug system, they will take it seriouly, then fix it.

    If there is any update about the problem, I will update this thread.

    Thank you for your understanding and wish you a nice day.

    Best Regards,


    Bruce Song [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    • Proposed as answer by Bruce Song Monday, August 01, 2011 9:35 AM
    • Marked as answer by Heinzi.at Monday, August 01, 2011 9:40 AM
    Friday, July 15, 2011 4:04 AM
  • Hi Bruce!

    Thanks a lot, it's good to know that someone is working on this! If there's anything I can help with, please let me know.

    Currently, we investigating various workarounds (using the text box twice (overlapping) inside a subreport seems to work most of the time, but it's extremely ugly), so any hints on how to workaround this issue would be helpful as well.

    Thanks,

        Heinzi

    Friday, July 15, 2011 10:53 AM
  • Hi Heinzi,

    I tried to find the workaround, but can't find a good one. Because the bug system is internal one, so, people outside can't track the status of the bug. If there is any update about the issue, I will notify you at the first time.

    Thank you for your understanding.

    Best Regards,


    Bruce Song [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.


    Monday, July 18, 2011 11:24 AM
  • Hi Bruce,

    Are there any news on this issue? I just noticed that the bug still exists in Access 2013...

    Thanks
        Heinzi

    Monday, May 27, 2013 9:29 AM
  • Hi Bruce,

    Are there any news on this issue? I just noticed that the bug still exists in Access 2013...

    Thanks
        Heinzi

    There seems to be a more generalized problem with textboxes in reports where the text is Rich Text. Sometimes textboxes should grow to show, say, 3 lines of text, but only show 2.

    What's the news on getting these bugs sorted out, please? It is 3½ years since it was reported.

    Wednesday, January 28, 2015 2:06 PM
  • There seems to be a more generalized problem with textboxes in reports where the text is Rich Text. Sometimes textboxes should grow to show, say, 3 lines of text, but only show 2.

    What's the news on getting these bugs sorted out, please? It is 3½ years since it was reported.

    Don't hold your breath.

    About a year ago, I submitted an official support request to Microsoft regarding a similar issue (service request ID 114032111284860) with a repro example that showed rich-text being cut off along page breaks.

    The support engineer informed me that Microsoft is aware of this issue, and it's not restricted to rich-text fields. There is currently no fix or reliable workaround available. He escalated the issue and requested a hotfix, which was denied. The reasoning given was that the code doing the page break calculations has not been modified for years and that any changes to it would be too risky, since they would affect all Access users.

    The only workaround mentioned was to avoid Calibri in reports, but there's no guarantee that this will reliably solve the problem.

    Best regards

    Wednesday, January 28, 2015 2:41 PM
  • Very unfortunate that Microsoft decides not solve this problem because the remedy of this problem earlier reports from Access users would be affected. I understand that this is annoying, but maintaining a problem, creates new problems. And not only affected earlier designed reports, but also new ones. And customers, and developers…

    I hope Microsoft will reconsider this issue and make the choice to not exclude improvements for old errors.

    Thursday, February 12, 2015 8:41 AM
  • Actually, this almost similar problem exist in Access 2000.

    Unfortunately, I can't recalled what is the exact solution. It's has to do with the Field control and the Detail control section of the properties.

    As far as I can recall, it's important how you place the field control in the Detail Section. Example, placing the can grow field control in a wrong position might make as if the first page of the report displaying information not to appear.


    Friday, February 13, 2015 3:21 AM
  • I'm curious. Will experiment with it - if there is time - and will certainly report here positive findings.
    Friday, February 13, 2015 8:21 AM
  • AccessVandal reminded me of that cutoff problem in 2000. My workaround was to put the text box at the bottom of the detail section. Set both the text box and the detail section to CanGo = Yes. I don't know if that will help you but it's worth a shot.

    Bill Mosca
    www.thatlldoit.com
    http://tech.groups.yahoo.com/group/MS_Access_Professionals

    Friday, February 13, 2015 9:05 PM
  • Thanks for your suggestion, Bill. Problem is we not only work with the DetailSection, but also with other sections (group-sections) and with sub reports... But al suggestions are very welcom to me. When time I'll try them all.

    Another problem is that I cannot reproduce the error: one of my customers reported the error. And the odd thing here is that at one system the error occured, and at another system not. Despite they used the same application...

    Saturday, February 14, 2015 5:32 AM
  • Thanks for your suggestion, Bill. Problem is we not only work with the DetailSection, but also with other sections (group-sections) and with sub reports... But al suggestions are very welcom to me. When time I'll try them all.

    Another problem is that I cannot reproduce the error: one of my customers reported the error. And the odd thing here is that at one system the error occured, and at another system not. Despite they used the same application...

    Did you check to see if both customers are on the same Office Build number?

    Bill Mosca
    www.thatlldoit.com
    http://tech.groups.yahoo.com/group/MS_Access_Professionals

    Monday, February 16, 2015 4:14 PM
  • I think it should be; they use my application with Access Runtime. Because I compile the applications before distribution (and distribute as .accde file), Access Runtime need the last version. But I'll check it.
    Monday, February 16, 2015 6:00 PM
  • Peter

    You might also try another font like a fixed width one (Courier New) or a simple font like Ariel to see if that works, but I doubt it if the issue is with how Access calculates the page break position.


    Bill Mosca
    www.thatlldoit.com
    http://tech.groups.yahoo.com/group/MS_Access_Professionals


    Monday, February 16, 2015 7:37 PM
  • Hi Bill,

    Yes, I'm aware, but my customers like to be flexible (and me to). Many times I use rich tekst format... so setting a font will play no part (I think). The posibility to use rich text will results in other calculations... Microsoft should reconsider this error I believe.

    Monday, February 16, 2015 7:46 PM
  • Hi Bill,

    Yes, I'm aware, but my customers like to be flexible (and me to). Many times I use rich tekst format... so setting a font will play no part (I think). The posibility to use rich text will results in other calculations... Microsoft should reconsider this error I believe.

    I completely agree with you, Peter. MS usually fixes these things in due time so this one must be very complicated or they've stopped focusing on desktop.

    Bill Mosca
    www.thatlldoit.com
    http://tech.groups.yahoo.com/group/MS_Access_Professionals

    Monday, February 16, 2015 8:13 PM
  • Hi Bill,

    When I got time I'll be testing thoroughly. When I find something benefit, I'll put it here.

    Monday, February 16, 2015 9:42 PM
  • Heinzi,

    That's correct, it's not the font types.

    What's the length of the text box characters?

    The length of characters are important as if the first page, the length of char exceeds certain limits, it will automatically go over to page 2.

    Not only that, if the second row/record had exceeded the character limit, it causes Access 2000 code to loop continuously or even crash.

    As I mentioned, the size of other Textboxes, the position of the textbox is important and as well as the size of the DetailSection. Also not forgetting other parts like Page Footer, Header, other Textboxes with CanGrow....etc.

    So, try reducing the character input into the Field/Column of the Textbox. If you need to have more character in one record or row, try spacing or paragraph spacing. 

    How Access Report calculates page positions....etc. or whatever, I don't know. All I'm saying, Access has problems with long strings of characters and it has a problem of moving it to the second page as what you are experiencing.

    Tuesday, February 17, 2015 5:20 AM
  • Heinzi,

    In addition to my previous post.

    I'm not sure you have Sorting And Grouping Headers added into the Report. But it doesn't matter, just that you need to know this.

    In the "Sorting And Grouping" Header Section properties, if you were to set "Repeat Section" to Yes, this will cause the Report to Loop continuously like "Formatting page, press Ctrl+Break to stop..." or will just crash.

    I have a Report as mention above. The only solution was to use the Report Header Section by using VBA so that it will appear like a "Sorting And Grouping" Header. But it's not perfect, at least the TextBox can truncate to the second page.

    I need to 2 "Sorting and Grouping" header, it doesn't work if you have many characters. I have advised my users to limit the length or use the my solution.

    This Repeat Section bug had been around Access 2000.

     

    Tuesday, February 17, 2015 7:57 AM
  • Hello,

    I have been reading this string with great interest and wondered if anyone has tried replacing the Text field type with a Memo field type, just to see what happens? Thanks.

    Cordially,

    John


    Thank you, John Portland, Maine

    Tuesday, February 17, 2015 4:31 PM
  • John,

    In addition to that, it's a Memo field.

    I forgot to add. For basic "Sorting and Grouping" Headers, without any VBA code in the "Group Header". It will work fine with the "Repeat Section" of the header.

    I have VBA code to hide the "Sorting and Grouping" Header for the first page, that may be the cause. Example, Hide Groupheader0 for Page 1. Hide Groupheader1 for Page 2,3,4...so on. (was resolved by alternative method but not perfect)

    But whatever, in regards to OP thread the problem, it's still there.


    • Edited by AccessVandal Wednesday, February 18, 2015 2:26 AM
    Wednesday, February 18, 2015 2:25 AM