Bug 90088 - BASE: Basic instruction moveToInsertRow doesn't scroll to actual insert row if there are more than approximately 45 records in a grid control
Summary: BASE: Basic instruction moveToInsertRow doesn't scroll to actual insert row i...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Database-Forms Macro-StarBasic
  Show dependency tree / graph
 
Reported: 2015-03-18 20:01 UTC by senya
Modified: 2024-12-23 16:04 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:

Attachments
File with the issue (13.31 KB, application/vnd.oasis.opendocument.database)
2015-03-18 20:01 UTC, senya 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description senya 2015-03-18 20:01:28 UTC 
Created attachment 114172 [details]
File with the issue

In the test file we have a table, a form, a grid in the form, that shows entries from the table. There is macro connected to form load event, that calls moveToInsertRow method.

If list is longer than 40-50 entries, then it doesn't show the rest entries and moveToInsertRow moves the cursor to the last shown entry, but not to the insert row. That makes it almost useless.

Was previously discussed there: http://ask.libreoffice.org/en/question/47478/adding-entries-to-a-long-grid/
Comment 1 Buovjaga 2015-03-21 16:21:50 UTC 
Please tell us exact steps to reproduce the issue and what we should see and what is seen instead.

Set to NEEDINFO.
Change back to UNCONFIRMED after you have provided the information.
Comment 2 Robert Großkopf 2015-03-21 19:18:49 UTC 
Could confirm the behavior.
You have to enable macros to see this:
Open the form.
Cursor moves to something like row 60, but there are 81 rows. 
The macro should move the cursor to row 82 to insert a new row.

This works right if you are not using a tablecontrol. Seems there is something like a cache-problem for the tablecontrol.
If you are using textboxes instead it doesn't show the right number of the row, but does show the field "ID" with <AutoValue>.

You could use the following workaround:

Sub MoveToInsertRow(oEvent as Object)
	oEvent.Source.Last()
	oEvent.Source.moveToInsertRow()
End Sub

This works for all versions. Moves the cursor to the last row, then jumps to the new row and also shows the right number of the row.

Have tested this with OpenSUSE 13.2 64bit and LO 4.3.5.2
Comment 3 tommy27 2016-04-16 07:24:16 UTC Comment hidden (obsolete)
Comment 4 Robert Großkopf 2016-04-16 09:18:18 UTC 
Bug also appears with LO 5.1.2.2 on OpenSUSE 64bit rpm Linux.
Have tested older versions: 
LO 3.6.7 on OpenSUSE the same buggy result.
LO 3.3.0 and 3.3.4 on OpenSUSE: all primary-key-fields of the tablecontrol will show <Auto Value> - so the bug couldn't be reproduced here because there is another buggy behavior.

Will set this bug to inherited from OOo, because I couldn't find any version before which will work right in this case.
Comment 5 QA Administrators 2017-05-22 13:25:12 UTC Comment hidden (obsolete)
Comment 6 Michael 2019-05-15 09:23:43 UTC 
Bug still appears with LO 6.1.5.2 on kUBUNTU 18.04 64bit.
Comment 7 QA Administrators 2021-05-15 04:18:05 UTC Comment hidden (obsolete)
Comment 8 Michael 2021-05-15 06:24:15 UTC 
Tested with actual MANJARO-KDE 
LibreOffice Version: 7.0.5.2
Build ID: 64390860c6cd0aca4beafafcfd84613dd9dfb63a
CPU threads: 16; OS: Linux 5.10; UI render: default; VCL: kf5
Locale: de-DE (de_DE.UTF-8); UI: de-DE
Calc: threaded

It's still the same issue: Open the database from Senya, allow macros. Open the form which should show a new line for a new record based on the macro. It shows record 47 but more than 80 records are in the source.
E.g.: Same behavior as Robert has described in #4.
Comment 9 Alex Thurgood 2021-05-19 13:12:03 UTC 
Confirming also with

Version: 7.1.2.2 / LibreOffice Community
Build ID: 8a45595d069ef5570103caea1b71cc9d82b2aae4
CPU threads: 8; OS: Mac OS X 10.16; UI render: default; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR
Calc: threaded
Comment 10 Alex Thurgood 2021-05-19 13:13:25 UTC 
@Lionel : guessing that this has something to do with the way the UI displays a cached subset of the resultset which doesn't get refreshed ?
Comment 11 Lionel Elie Mamane 2021-05-19 16:16:06 UTC 
There are two moveToInsertRow() in the API.
com::sun::star::sdbc::XResultSetUpdate::moveToInsertRow()
or
com::sun::star::form::runtime::FormFeature::MoveToInsertRow()

My guess is about the latter. 

(In reply to Alex Thurgood from comment #10)
> @Lionel : guessing that this has something to do with the way the UI
> displays a cached subset of the resultset which doesn't get refreshed ?

My guess is more that it is linked to the lazy loading of rows (when the UI displays a "*" next to the number of rows to say that not all rows are loaded yet). In that case, it can probably be worked around by:

moveToLast() to force loading of all rows, then only moveToInsertRow()
Comment 12 QA Administrators 2024-11-07 03:15:08 UTC Comment hidden (obsolete)
Comment 13 Robert Großkopf 2024-11-07 07:33:02 UTC 
Behavior is still the same with
Version: 24.8.3.1 (X86_64) / LibreOffice Community
Build ID: 65412f067af443213e726c93f137ccc85c9a1e06
CPU threads: 6; OS: Linux 6.4; UI render: default; VCL: kf5 (cairo+xcb)
Locale: de-DE (de_DE.UTF-8); UI: de-DE
Calc: threaded