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.
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.
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.
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.
(forgot to say I reproduced the problem with 4.3 since master source fail to build)
wrong way, even by forcing to "false" when I click the button, there's still the pb :(
I could also reproduce the problem without using the custom button, just by using the refresh button from UI (in form navigation toolbar)
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.
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.
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.
*** Bug 79861 has been marked as a duplicate of this bug. ***
(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.
Lionel: Thank you indeed for the detailed explanation! :)
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
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.