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.
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.
Adding self to CC if not already on
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.
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.
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.
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.
See comment & screenshot
(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.