Download it now!
Bug 79427 - EDITING: Buttons for refreshing a form sets row after last
Summary: EDITING: Buttons for refreshing a form sets row after last
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
4.3.0.0.alpha1
Hardware: All Linux (All)
: high blocker
Assignee: Lionel Elie Mamane
URL:
Whiteboard: target:4.4.0 target:4.3.0.2
Keywords: regression
: 79861 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-05-29 20:03 UTC by Robert Großkopf
Modified: 2014-06-18 09:46 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Open the form - content of name disappears when pressing the button in LO 4.3 (11.17 KB, application/vnd.oasis.opendocument.base)
2014-05-29 20:03 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 2014-05-29 20:03:01 UTC
Created attachment 100122 [details]
Open the form - content of name disappears when pressing the button in LO 4.3

Open the attached database.
Open the form.
Press the button, which is connected to Action → Refresh form.
Up to LO 4.2.5.1 the form shows the same row as before.
After refreshing in LO 4.3.0 the form shows a new row, which doesn't exist. The field "Name" would be empty.

The cursor has gone after the last row of the table by refreshing the table.
Comment 1 Thomas Hackert 2014-05-30 07:33:02 UTC
Good morning Robert, *,
I can confirm your bug with LO Version: 4.3.0.0.beta1 Build-ID: 2e39c7e59c8fc8b16a54c3d981dceef27fb0c07f (parallel installed, following the instructions from https://wiki.documentfoundation.org/Installing_in_parallel) with installed Germanophone lang- as well as helppack under Debian Testing i686 ... :( If I press the button "Button: Refresh Form", it increments the number of the record set to an non-existing "2" with an empty name field ... :( If I try the same with LO Version: 4.1.6.2 Build-ID: 40ff705089295be5be0aae9b15123f687c05b0a with Germanophone lang- as well as helppack on the same system, the number of the record set stays at "1" and the name field shows "Robert" instead of emptying it. LO Version: 4.2.3.3 Build-ID: 882f8a0a489bc99a9e60c7905a60226254cb6ff0 (also parallel installed and with Germanophone lang- as well as helppack) shows the same behaviour as 4.1.6.2: It stays at record set "1" with "Robert" in the name field :)
HTH
Thomas.
Comment 2 Robert Großkopf 2014-06-10 14:35:12 UTC
This bug would show wrong relations, when you have a form with subforms. It could show empty subforms as described in bug79861. Subforms only would work right if there is a tablecontrol as field in the subform.

Many databases wouldn't work if this bug wouldn't not be fixed. Seems to be a blocker for LO 4.3.
Comment 3 Julien Nabet 2014-06-15 08:26:47 UTC
Lionel:
I tried a gdb session by putting break at 2 locations:
http://opengrok.libreoffice.org/xref/core/forms/source/runtime/formoperations.cxx#256
http://opengrok.libreoffice.org/xref/core/svx/source/form/fmshell.cxx#1163

Then I gave a try and retrieved _nFeature from formoperations + bEnable from fmshell: (sometimes a "_nFeature" wasn't associated with a "bEnable")
1) At the opening:
11 11  11
18(true) 15(false) 13(false) 12(false) 9(false) 7(false)
6(false) 11(true) 5(false) 17 4(false) 14(true) 3(false) 19(false)
2 10(false) 1 8(false) 
3(false) 5(false) 4(false) 6(false) 7(false)
10(false) 1 2 8(false) 9(false) 18(true) 12(false) 13(false) 14(true)
15(false) 17 11(true) 19(false)

2) when click on the button:
11 11 11 
3(true) 5(true) 4(true) 6(true) 7(false) 
10(false) 1 2 8(false) 9(false) 18(true) 12(false) 13(false) 14(true)
15(false) 17 11(true) 19(false)
(so less _nFeature and 3, 5, 4, 6 are true in 2) instead of false.

I wonder if it could be a problem with some sal_Bool->bool conversion but am a bit stuck for the moment.
Comment 4 Julien Nabet 2014-06-15 08:28:50 UTC
(forgot to say I reproduced the problem with 4.3 since master source fail to build)
Comment 5 Julien Nabet 2014-06-15 08:59:20 UTC
wrong way, even by forcing to "false" when I click the button, there's still the pb :(
Comment 6 Julien Nabet 2014-06-15 20:53:36 UTC
I could also reproduce the problem without using the custom button, just by using the refresh button from UI (in form navigation toolbar)
Comment 7 Commit Notification 2014-06-16 06:48:58 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=44cd9a17ca55bf86340f39e01a2b7571cc397ca6

fdo#79427 after execute() a ResultSet is expected to be BeforeFirst



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 8 Julien Nabet 2014-06-16 11:03:02 UTC
Great this is fixed! :)
Lionel: just for curiosity, how did you find the cause of the problem? Indeed, I spent a lot of time and was completely stuck. The goal of my question is to know other ways to investigate.
Comment 9 Commit Notification 2014-06-16 19:59:16 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=767e15343fdedffce513fd26ce17ee6003936117

clean up fdo#79427 fix: force BeforeFirst only at execute(), not updateRow()



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 10 Lionel Elie Mamane 2014-06-16 20:07:10 UTC
*** Bug 79861 has been marked as a duplicate of this bug. ***
Comment 11 Lionel Elie Mamane 2014-06-16 20:19:24 UTC
(In reply to comment #8)
> Great this is fixed! :)
> Lionel: just for curiosity, how did you find the cause of the problem?
> Indeed, I spent a lot of time and was completely stuck. The goal of my
> question is to know other ways to investigate.

I started from

break FmFormShell::Execute
break FmXFormShell::ExecuteFormSlot

and then single-stepped ("s" in gdb) my way through, using "finish" when I get into utility functions that don't interest me, such as css:uno:Reference or OUString constructors / destructors.

In this way, I bore down through:

svx::FormControllerHelper::impl_operateForm_nothrow
frm::FormOperations::execute
frm::ODatabaseForm::reload_impl
frm::ODatabaseForm::executeRowSet

At this level, I stopped stepping through, and started stepping "over" line per line ("n" in gdb).

There I saw:

       if (bMoveToFirst)
        {
            // the row set is positioned _before_ the first row (per definitionem), so move the set ...
            try
            {
                // if we have an insert only rowset we move to the insert row
                next();


Stepping through the next() and its m_xAggregateAsRowSet->next(), I saw that *before* the next(), the ResultSet was already on the first record, instead of "before first". Knowing that the expectation that a just-executed ResultSet must indeed be at "before first" is the right expectation, I deduced that clearly the problem was before. Stepping through the execution of next(), I see that upon reexecution, m_aBookmark (of dbaccess::ORowSet) is not reset, I look more and the whole position state (m_bIsBeforeFirst, etc) is not reset on reexecution.
Comment 12 Julien Nabet 2014-06-16 20:33:11 UTC
Lionel: Thank you indeed for the detailed explanation! :)
Comment 13 Jacques Guilleron 2014-06-17 22:17:11 UTC
Hi all,

Works now as expected with LO 4.4.0.0.alpha0+
Build ID: 3e82897353e576dc6e3fbf55371fda5a0c3415df
TinderBox: Win-x86@39, Branch:master, Time: 2014-06-17_08:55:34
on Windows 7 Home Premium
Thank you, Lionel. Your detailed explanations are welcomed too.

Jacques
Comment 14 Commit Notification 2014-06-18 09:46:58 UTC
Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "libreoffice-4-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=98986a5167438808871e8094dbf815c72282ca0b&h=libreoffice-4-3

fdo#79427 after execute() a ResultSet is expected to be BeforeFirst


It will be available in LibreOffice 4.3.

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.