none
Report Controls Jump Elsewhere When Moving

    Question

  • Using Access 2013 on Windows 10.

    When I try to move (either mouse or keyboard) some controls on a particular report, they jump to some other position.
    Often into a different section.
    I've only found one post describing a similar issue and it referred to reaching the design size limit for a section. This is not my case.
    Normally when selecting a control, an area highlights on the rulers, representing the height and width of the selection. For the controls that jump, only a single line shows on the vertical ruler and it is not where the control is located. It is where it will jump to.

    There is no layout applied to the controls. When I select them, the remove layout option is disabled.

    If I copy/paste the control, the new control behaves normally.
    If I cut/paste the control, it retains the erratic behavior.

    I have also tried:
    Copy/Paste the report.
    Save the report with another name.
    Save as text/load from text. Also reviewed the text file and nothing jumps out.
    Create a new blank database and import the report.
    Decompile.
    Compact/Repair.
    Repair Office.
    Disabled add-ins.

    It acts like there is some control property that affects this, but I can't find any even close.

    Does anyone have a solution to stop this erratic behavior?

    Has anyone else even seen it?

    Monday, November 20, 2017 3:54 PM

All replies

  • Hello,

    Could you please share a sample database here? 

    You could upload the db into OneDrive and share the link here. Please visit Share OneDrive files and folders.

    Regards,

    Celeste


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Tuesday, November 21, 2017 1:39 AM
    Moderator
  • Thanks for the reply Celeste.

    Here is the link for a db with only the report and it's subreports. Since the issue is only in design view, there is no need for tables. 

    https://1drv.ms/f/s!AnirIikvk_C0hlQ0KFdw90Tkn_P3

    The report in question is rptJCSprinkler.
    I've removed all code and also tried it on another machine, with the same result.
    The offending controls are in red. Most can't be moved at all without jumping, but a few can be moved a varying distances, before they will jump.

    Tuesday, November 21, 2017 3:13 PM
  • Hello,

    The issue do exist. After some tests, i find the issue occurs when the height of all sections is more than about 20 inch. If the height of controls in the whole report is more than about 20 inch, controls could not be moved correctly.

    I suggest you apply layout and use the built-in commands in Arrange tab to arrange controls.

    Regards,

    Celeste


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Wednesday, November 22, 2017 4:03 AM
    Moderator
  • Thanks for the reply. However, what you are saying is not practical at all.
    You are saying to design the report the way Microsoft wants it instead of the way the client, who is paying for it, wants it.
    I've been working with Access since version 1.0 and never ran into this in the past, including with reports much longer than this.

    I can open the same db in Access 2007 and there is no problem.
    Can you provide a link to documentation that states that this is a new limitation of Access 2013?
    Seems to me that it is a bug which is severely limiting report design.

    Could an MVP please weigh in here?

    • Edited by Alphonse G Wednesday, November 22, 2017 12:23 PM additional thought
    Wednesday, November 22, 2017 11:31 AM
  • You weren't trying to be dismissive to Celeste, right?

    From a bit of testing in A2010 it seems she is right. This is what I did:

    Increase height of EpStandard Header by about 2"
    Select the red items and move them down a quarter inch at a time. Very quickly you will find you have reached the limit.
    In the Report Header, move the bottom (Page header) up by an inch.
    Go back to the section. Observe you can now move them down about an inch more and the same behavior repeats.

    As any tool, this one has limitations, some documented some not. We find a way to work within them, or find another tool.


    -Tom. Microsoft Access MVP

    Wednesday, November 22, 2017 2:27 PM
  • Thanks for jumping in Tom.
    The thing is that, this was not a limitation in Access 2007 and prior versions, which it is why it seems like a bug to me.
    In fact back in Access 97, I had built a system for mortgage documents which really pushed the limit on section sizes, but there was nothing like this.
    I don't even understand how no one else has reported this.

    I couldn't find the specifications for 2013, but the specifications for 2016 (https://support.office.com/en-us/article/Access-2016-specifications-0cf3c66f-9cf2-4e32-9568-98c1025bb47c), don't indicate anything like this.

    Wednesday, November 22, 2017 3:02 PM
  • Just thinking out load hear. Do you suppose that the newer versions somehow read the default paper size in your printer and restrict what you can do on a report based on that? I use 2007 and haven't seen this problem. Like i said, just guessing. Maybe if the paper height is 11" for example, the new versions won't allow you to even change a report where the total combined height is greater than 11". That's the only thing I can think of.
    Wednesday, November 22, 2017 3:27 PM
  • Thanks, Lawrence, good thought.
    I just tried changing my default printer with a couple of different paper sizes as the default. No joy.
    You are correct, the problem does not exist in 2007. I can open the same report in 2007 and move controls with no problem.

    Wednesday, November 22, 2017 3:46 PM
  • Would this have anything to do with whether the selection is "partially enclosed" or "fully enclosed"?

    https://support.office.com/en-us/article/Customize-design-settings-for-objects-in-your-database-0DDA785A-5C19-487B-8E7F-6DD3957810AD

    Again, just guessing.

    Wednesday, November 22, 2017 4:14 PM
  • Thanks Lawrence, unfortunately, no difference. But, I'm willing to try just about anything.
    Wednesday, November 22, 2017 4:20 PM
  • I was thinking later that what would likely work is to put some of the sections in their own subreport, then put that subreport on the main report and make it very small vertically, with CanGrow on. Then I would expect Access will be able to compose the report just fine at runtime, while at design time to can easily stay within the (apparently changed) max height.

    -Tom. Microsoft Access MVP

    Wednesday, November 22, 2017 4:41 PM
  • Thanks Tom,

    Yes, I'm sure that would work and I can resort to that if need be.
    It's just that, something like that should not be necessary.

    Wednesday, November 22, 2017 4:47 PM
  • And you are using Design View and not Layout View, is that right?
    Wednesday, November 22, 2017 5:42 PM
  • And you are using Design View and not Layout View, is that right?

    Correct.
    Wednesday, November 22, 2017 5:47 PM
  • Hello,

    I test your db in Access 2007-2016. It works fine in Access 2007. The problem exists from Access 2010 -2016. However, no document indicates this is a limit. I suggest you go to File -> Feedback to submit the issue. 

    Regards,

    Celeste


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Thursday, November 23, 2017 3:15 AM
    Moderator
  • Thanks for testing this in other versions, Celeste.

    So, are you confirming that this is a bug?

    I don't see File -> Feedback in Access 2013. Is it located somewhere else in 2013?

    Thursday, November 23, 2017 11:16 AM
  • Hello,

    To confirm if it is known issue or bug, i suggest you open a ticket and contact the Microsoft professional support. You won't be charged if the support engineer determines that the issue is the result of a bug.

    In Access 2013, you could find the feedback button under the minimize,maximize, and close button. You could see the unhappy face when you click file.

    Regards,

    Celeste


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Friday, November 24, 2017 2:06 AM
    Moderator
  • Thanks, but there is nothing under the min/max/close buttons.

    I will try to open a support ticket.

    Friday, November 24, 2017 2:13 AM
  • I am using Office C2R. It may cause the difference. I suggest you mark helpful post or your post as answer to close this thread. Thanks for your understanding.


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Friday, November 24, 2017 2:35 AM
    Moderator
  • Thanks,

    I'll close it once I get the results of my support ticket, which, as you probably know, can take a few weeks.

    Friday, November 24, 2017 11:24 AM
  • Good luck and we would appreciate if you could share the result here. 

    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Saturday, November 25, 2017 5:42 AM
    Moderator
  • The result of the support ticket is:

    "the issue has been identified as a regression/product defect,  this would be fixed in upcoming updates however at the moment we have not been provided an ETA as to how soon this may happen"

    I was also asked to post it on access.uservoice, which I did, so it will probably help if others vote for it.

    https://access.uservoice.com/forums/319956-access-desktop-application/suggestions/32661538-fix-confirmed-bug-report-controls-jump-elsewhere

    Thursday, December 28, 2017 1:46 PM
  • The result of the support ticket is:

    "the issue has been identified as a regression/product defect,  this would be fixed in upcoming updates however at the moment we have not been provided an ETA as to how soon this may happen"

    I was also asked to post it on access.uservoice, which I did, so it will probably help if others vote for it.

    https://access.uservoice.com/forums/319956-access-desktop-application/suggestions/32661538-fix-confirmed-bug-report-controls-jump-elsewhere

    Thanks for the information. I have voted the feedback and hope the issue would be fix soon. You may mark your post and it would be of great help for others.


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Friday, December 29, 2017 1:58 AM
    Moderator
  • Thanks for voting. I don't see why anything should be marked as an answer as there is no real solution unless Microsoft fixes it.
    Friday, December 29, 2017 2:08 AM
  • OK. Hope the issue could be fixed soon.

    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Friday, December 29, 2017 2:14 AM
    Moderator