Bug Hunting Session
Bug 43928 - EDITING Forms - tabstops in tablecontrols could not be changed
Summary: EDITING Forms - tabstops in tablecontrols could not be changed
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Database-Forms
  Show dependency treegraph
 
Reported: 2011-12-18 06:27 UTC by Robert Großkopf
Modified: 2019-06-16 20:19 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Open the form "Konto" and set the cursor in the tablecontrol. Move the cursur with tabstop ... (16.50 KB, application/vnd.oasis.opendocument.database)
2014-12-13 12:00 UTC, Robert Großkopf
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Großkopf 2011-12-18 06:27:47 UTC
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.
Comment 1 Florian Reisinger 2012-01-22 08:20:51 UTC
What are tablecontrols?
Sample document please?
Screenshots?
.
.
.
After that please mark as unconfirmed
Thanks
Comment 2 Drew Jensen 2012-01-22 08:53:50 UTC
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.
Comment 3 Robert Großkopf 2014-12-13 12:00:19 UTC
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.
Comment 4 Alex Thurgood 2015-01-03 17:39:07 UTC Comment hidden (no-value)
Comment 5 Julien Nabet 2015-03-14 10:01:55 UTC
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.
Comment 6 Julien Nabet 2015-03-14 10:54:00 UTC
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?
Comment 7 Robert Großkopf 2015-03-14 11:23:58 UTC
(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?
Comment 8 Julien Nabet 2015-03-14 11:29:43 UTC
(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) :-)
Comment 9 Julien Nabet 2015-03-14 20:22:46 UTC
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
Comment 10 QA Administrators 2015-10-14 19:50:42 UTC Comment hidden (obsolete)
Comment 11 Robert Großkopf 2015-10-15 05:54:27 UTC
(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.
Comment 12 Heiko Tietze 2015-10-15 08:20:43 UTC
(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.
Comment 13 QA Administrators 2016-05-09 20:07:33 UTC Comment hidden (obsolete)
Comment 14 Robert Großkopf 2016-05-10 05:42:02 UTC
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.
Comment 15 Heiko Tietze 2016-09-12 13:21:17 UTC
(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.
Comment 16 QA Administrators 2018-06-13 02:36:09 UTC Comment hidden (obsolete)
Comment 17 Robert Großkopf 2018-06-15 06:24:01 UTC
Bug still exists with LO 6.0.5.1, OpenSUSE 42.3 Leap, 64bit rpm Linux.
Comment 18 QA Administrators 2019-06-16 02:58:18 UTC Comment hidden (obsolete)
Comment 19 Robert Großkopf 2019-06-16 06:21:16 UTC
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.