When using tablecontrols in a form there could be fields which are not editable. I could choose this. I could also choose that they are not activated. Then the cursor is hidden because I could not choose that there are no tabstops in this fields. I don't need tabstops for a field which is not editable and not activated.
What are tablecontrols? Sample document please? Screenshots? . . . After that please mark as unconfirmed Thanks
I believe I know what the OP is talking about. To reproduce. Open a form with a table control in edit mode. Select any column and open the property editor. Set the following propertied: Enabled = False Read Only = True Save and close the form Open for data entry mode. Use the tab key to move from field (column) to field in the table control. The input focus will switch to the disabled, read only, column. No cursor is displayed, in fact no key board interaction is excepted. - meaning you can not use the keys to highlight and copy the contents of the field, which would be the only reason to focus on the control. (you can highlight the contents with the mouse). Not sure if this is a new behavior however. I don't think so.
Created attachment 110813 [details] Open the form "Konto" and set the cursor in the tablecontrol. Move the cursur with tabstop ... Nothing happend with this buggy behavior. When editing an example-database for German Handbook I created a form, which is a good example for this bug. Open the form. Set the cursor in the first field of the tablecontrol. Push the tabulator. The cursor will move from the first field to the next. Push the tabulator again and again. If the cursor reaches the last fields the cursor wouldn't be seen any more - the fields aren't activated and aren't writable. After a while the cursor appears again in the next row.
Adding self to CC if not already on
On pc Debian x86-64 with master sources updated yesterday, I could reproduce this. In fact the cursor doesn't appear in the 5 last columns of the table.
Ok after re reading all the comments and runned some tests again, I've just understood the fact the cursor wasn't appeared because of the columns had "Enable" property to False. ux-team: what should be behavior of the cursor? 1) Just jump to the next enabled column? (or to the new line if there's no more enabled column on the row) 2) Don't care if column is enabled or not, the cursor should be there in all cases? 3) As it is now? cursor disappear where column is not enable (IMHO awkward choice) 4) other?
(In reply to Julien Nabet from comment #6) > ux-team: what should be behavior of the cursor? > 1) Just jump to the next enabled column? (or to the new line if there's no > more enabled column on the row) > 2) Don't care if column is enabled or not, the cursor should be there in all > cases? > 3) As it is now? cursor disappear where column is not enable (IMHO awkward > choice) > 4) other? Don't know what is ux-team. 1) - is the best solution. Why should I press Tab, if there couldn't be made any input. 3) - is irritating for every user - Cursor has been gone for a while, will drink a cup of tea?
(In reply to robert from comment #7) > Don't know what is ux-team. > 1) - is the best solution. Why should I press Tab, if there couldn't be made > any input. > 3) - is irritating for every user - Cursor has been gone for a while, will > drink a cup of tea? I agree with you, 1) seems the best solution. 3) is awkward and 2) is useless or worse, irritating. Putting ux-team means we need advice of people which work in User eXperience or UI if you prefer. Perhaps they'd think about another best solution. So NEEDINFO is not not addressed to you but to ux-team. Anyway, I'm trying to find a code pointer to apply 1) :-)
Badfully, I've just got a code pointer to begin: #0 DbGridControl::CursorMoved (this=0x35260d0) at /home/julien/compile-libreoffice/libreoffice/svx/source/fmcomp/gridctrl.cxx:2093 #1 0x00002aaad863af30 in dbaui::SbaGridControl::CursorMoved (this=0x35260d0) at /home/julien/compile-libreoffice/libreoffice/dbaccess/source/ui/browser/sbagrid.cxx:917 #2 0x00002aaaaf97f634 in BrowseBox::GoToColumnId (this=0x35260d0, nColId=6, bMakeVisible=true, bRowColMove=false) at /home/julien/compile-libreoffice/libreoffice/svtools/source/brwbox/brwbox1.cxx:1613 #3 0x00002aaaaf97f2ba in BrowseBox::GoToColumnId (this=0x35260d0, nColId=6) at /home/julien/compile-libreoffice/libreoffice/svtools/source/brwbox/brwbox1.cxx:1560 #4 0x00002aaaaf997c74 in BrowseBox::Dispatch (this=0x35260d0, nId=734) at /home/julien/compile-libreoffice/libreoffice/svtools/source/brwbox/brwbox2.cxx:1926 #5 0x00002aaaaf9aa681 in svt::EditBrowseBox::Dispatch (this=0x35260d0, _nId=734) at /home/julien/compile-libreoffice/libreoffice/svtools/source/brwbox/editbrowsebox.cxx:608 #6 0x00002aaacae8391b in DbGridControl::Dispatch (this=0x35260d0, nId=734) at /home/julien/compile-libreoffice/libreoffice/svx/source/fmcomp/gridctrl.cxx:2935 #7 0x00002aaaaf9aacc6 in svt::EditBrowseBox::PreNotify (this=0x35260d0, rEvt=...) at /home/julien/compile-libreoffice/libreoffice/svtools/source/brwbox/editbrowsebox.cxx:717 #8 0x00002aaacae85368 in DbGridControl::PreNotify (this=0x35260d0, rEvt=...) at /home/julien/compile-libreoffice/libreoffice/svx/source/fmcomp/gridctrl.cxx:3236 #9 0x00002aaab181b1eb in vcl::Window::PreNotify (this=0x3529820, rNEvt=...) at /home/julien/compile-libreoffice/libreoffice/vcl/source/window/event.cxx:56 #10 0x00002aaaaf9a5824 in svt::ListBoxControl::PreNotify (this=0x38b1ee0, rNEvt=...) at /home/julien/compile-libreoffice/libreoffice/svtools/source/brwbox/ebbcontrols.cxx:168 #11 0x00002aaab181b1eb in vcl::Window::PreNotify (this=0x3998520, rNEvt=...) at /home/julien/compile-libreoffice/libreoffice/vcl/source/window/event.cxx:56 #12 0x00002aaab19b0573 in ImplWin::PreNotify (this=0x3998520, rNEvt=...) at /home/julien/compile-libreoffice/libreoffice/vcl/source/control/ilstbox.cxx:2640 #13 0x00002aaab191a0ce in ImplCallPreNotify (rEvt=...) at /home/julien/compile-libreoffice/libreoffice/vcl/source/window/winproc.cxx:60
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/FDO/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team This NEEDINFO message was generated on: 2015-10-14
(In reply to QA Administrators from comment #10) > Dear Bug Submitter, > ... > This NEEDINFO message was generated on: 2015-10-14 NEEDINFO is addressed to ux-team. See comment #8.
(In reply to Julien Nabet from comment #6) > ux-team: what should be behavior of the cursor? In general, controls that are in the tabstop sequence receive the focus. So a readonly input will still get the focus unless it's enabled property is set to false. This behavior is common in every environment and widgetset. The second part of the question is about the cursor. I don't see any reason to hide it for readonly controls, in fact that contradicts the axiom of affordance and discoverability. Sounds more like a bug to me.
Dear Bug Submitter, Please read this message in its entirety before proceeding. Your bug report is being closed as INVALID due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team This INVALID Message was generated on: 2016-05-09
I will set this back to "NEW", because all informations were supported. See comment 8. No info of UX-team, but all infos of the bugreporter were given.
(In reply to Julien Nabet from comment #6) > ux-team: what should be behavior of the cursor? > 1) Just jump to the next enabled column? (or to the new line if there's no > more enabled column on the row) This one please.
** 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
Bug still exists with LO 6.0.5.1, OpenSUSE 42.3 Leap, 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
Same buggy behaviour in LO 6.2.4.2 on OpenSUSE 15, 64bit rpm Linux Cursor disappears when moving through a tablecontrol with tabs and there are fields, which aren't activated. Zhere is no changing of the tabstop available.
Please add keyword 'needsUXEval' and CC 'libreoffice-ux-advise@lists.freedesktop.org' if input from UX is needed.
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
Bug still exists with LO 7.3.1.2, OpenSUSE 15.3, 64bit rpm Linux.
UX input has been given in comment 12. As a remark: consider also screen readers for disabled users. This makes a tab stop at read only controls necessary. The question is rather what exactly needs to be changed. => needsDevAdvice
Still the same bug in Version: 24.2.1.2 (X86_64) / LibreOffice Community Build ID: db4def46b0453cc22e2d0305797cf981b68ef5ac CPU threads: 6; OS: Linux 5.14; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded