Created attachment 134112 [details] Open the database. Switch trough the form with CTRL+Tab as described. Open the attached database. Macros could be ignored. Open the form. Cursor is set to first tablecontrol, "id1". Press CTRL+Tab. Cursor moves to second tablecontrol, "id2". Press CTRL+Tab. Nothing changes any more. You could press CTRL+Tab as much as you want ... Close the form. Open the form for editing, not for input data. Switch design-mode off. You could see data now. Cursor is set to first tablecontrol. Now do the same as above. Pressing CTRL+Tab moves the cursor from first tablecontrol to second tablecontrol to third tablecontrol to fourth tablecontrol and when arriving the first tablecontrol again it is set to next row. CTRL+Tab only works right when form is opened for editing and design-mode is switched off. CTRL+Tab is buggy when form is opened for input data.
I can confirm this on Windows 10. It seems that this misbehaviour of Ctrl+Tab only happens, when one tries to get to the next form starting from a tablegrid. It works fine when starting from a single field, eg. a text field, a formatted field, a combo box or a check box.
(In reply to Gerhard Weydt from comment #1) > It seems that this misbehaviour of Ctrl+Tab only happens, when one tries to > get to the next form starting from a tablegrid. It works fine when starting > from a single field, eg. a text field, a formatted field, a combo box or a > check box. Can't confirm. Test the second attachment: Single fields, followed by a tablecontrol. You move to the tablecontrol but can't switch back.
Created attachment 134115 [details] Same bug with single fields an a tablecontrol - no way back while input data.
Robert gathered from my comment #2 a meaning I didn't intend to convey, and therefore thought he had to correct it. But in fact we mean the same. After a private dialog I think we have now agreed on the following statement: There should be a way, in data entry mode, to jump to the (first element in the) next form, similarly to edit mode, where you can jump to the next form by Ctrl+Tab. This does normally not work for forms containing table grids: when the cursor is within a table grid nothing happens. It does jump to the next form, though, when the cursor is within a single field. If you combine table grids and single grids in one form, the situation is more complicated. It seems that Ctrl+Tab has two different meanings: 1. if the focus is in a single field, it jumps to te next form. 2. if the focus is in a tablegrid, it leaves the table grid; this may result in a jump to the next form, but if there are some single fields in the form, the cursor moves just to the first of these fields (this may depend on the tab-order or the order displayed in the navigator). The above statements relate to the situation that you opened the form document in data entry mode. If you open it in edit mode and switch off design mode (which I name mode B for the moment), then you should ideally be in the same mode as in data entry (which I name mode A). But there are grave differences: 1. if you have only table grids, mode B seems to work perfectly: Ctrl+Tab jumps from one form to the next; in mode A this normally doesn't work 2. if you have also single fields within a form, Ctrl+Tab will not work for single fields in mode B, whereas it works for them in mode A. In mode A the focus moves from a table grid to the first single field or from a single field - as it seems - to the first (in the sense of tab order) element of the next form. There is no use providing examples or test documents, anyone tackling this principal problem will have to create his own test cases after investigating the existing code. Robert's example may be a starting point, though. Rest it to say that this an important issue regarding accessability, which seems to have been a little bit overlooked in Base.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
It's the same buggy behavior in LO 6.0.5.2 on OpenSUSE 42.3 64bit rpm Linux
Dear robert, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still the same buggy behaviour in Version: 6.3.0.0.beta1 - tested with OpenSUSE 15 64bit rpm Linux.
Dear Robert Großkopf, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still the same buggy behaviour in Version: 7.1.4.2 - tested with OpenSUSE 15.2 64bit rpm Linux.
Dear Robert Großkopf, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still the same buggy behavior in LO 7.5.4.2 on OpenSUSE 15.4 64bit rpm Linux. Ctrl+Tab works, when form has been opened for editing and design mode is switched off. Ctrl+Tab only works once if form has been opened for input data.