Download it now!
Bug 82591 - BASE: Absolute record counter in form navigation bar goes to "1" when edit existing record, click on second field control
Summary: BASE: Absolute record counter in form navigation bar goes to "1" when edit e...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: high normal
Assignee: Lionel Elie Mamane
URL:
Whiteboard: target:5.1.0 target:5.0.0.0.beta2
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-14 02:34 UTC by Doug
Modified: 2016-10-25 19:24 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
demonstration document - use suggested steps in Form1 (11.17 KB, application/vnd.oasis.opendocument.base)
2014-08-14 02:34 UTC, Doug
Details
problem with count of all records in navigation window-screenshot (738 bytes, image/png)
2015-07-17 03:10 UTC, Doug
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Doug 2014-08-14 02:34:17 UTC
Created attachment 104596 [details]
demonstration document - use suggested steps in Form1

Sample attached.

1.  Open Form1
2.  Navigate to third or fourth record.
3.  Click text field.  Add more text.
4.  Click to the other field control (the number field).

UNEXPECTED RESULT:  Look down at the navigation bar/record selector, specifically the box in the navigation bar containing the "absolute record."  You originally navigated to third or fourth record (and the "absolute record" box had said so), but now the "absolute record" is "1".  If you navigate forward, it will jump back to the correct number (i.e., four or five).  Interestingly, when one clicks "undo data entry" menu button, "absolute record" also jumps back to correct position.

EXPECTED RESULT:  This edit/update operation should result in no change to the "absolute record" in the navigation bar, because it did not change the selected record.


Bug encountered in Windows7/LO 4.3.0.4  and OpenSuse13.1/LO 4.1.6.2.
Comment 1 Robert Großkopf 2014-08-14 05:33:55 UTC
I could confirm this buggy behavior. Doesn't work in any LO-version. Have tested some versions (4.1.*, 3.6.* and also 300beta1). Must be a very old undetected bug, inherited from OOo.

If you edit the table the same way there is no changing of the "absoulte record". The form should do this the same way.

Tested here with OpenSUSE 12.3 64bit rpm Linux.
Comment 2 Alex Thurgood 2015-01-03 17:38:47 UTC
Adding self to CC if not already on
Comment 3 Robert Großkopf 2015-05-24 15:28:45 UTC
I will raise the Importance. Have tried to reload a form by a macro, but can't position the form to the right record, because
loRow = oForm.getRow
will always result '0' if I have changed anything inside the record before and will execute a macro by a button in the form.

At this moment you have to execute getRow while switching to next row, save this in a global variable and use this variable to set
oForm.Absolute(loRow)
to the right row.
Comment 4 Commit Notification 2015-05-30 15:34:54 UTC
Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=8607f8b552d917f064b2ebfd60ffcef1e6f92bb0

tdf#82591 ORowSetBase::getRow handles insert row correctly

It will be available in 5.1.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 5 Commit Notification 2015-05-30 15:37:22 UTC
Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "libreoffice-5-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=bd09c6a0ba4ab179e549812d456a1674ab3ae6e8&h=libreoffice-5-0

tdf#82591 ORowSetBase::getRow handles insert row correctly

It will be available in 5.0.0.0.beta2.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 6 Doug 2015-07-17 03:10:09 UTC
Created attachment 117289 [details]
problem with count of all records in navigation window-screenshot

Please consider whether the patch is connected to a rendering artifact for the number in the navigation bar representing the number of records at the bottom of the form.  It looks like two numbers are being drawn over one another, "of 3|4".  This screenshot is after following the directions for reproducing Bug 84069 in attachment 1 there.
Comment 7 Doug 2015-07-17 03:10:40 UTC
See comment & screenshot
Comment 8 Lionel Elie Mamane 2015-07-17 06:02:32 UTC
(In reply to Doug from comment #6)

> Please consider whether the patch is connected to a rendering artifact for
> the number in the navigation bar representing the number of records at the
> bottom of the form.  It looks like two numbers are being drawn over one
> another, "of 3|4".  This screenshot is after following the directions for
> reproducing Bug 84069 in attachment 1 there.

Different bug. Please do that in new bug, not here.