With 5.0.0.5 Base I've started having problems with subforms In my application I have a number of tables, two of which are Subscribers and Payments which are linked on a common column Subscriber_ID. There is a third table that is used to filter the data in the subscribers table only ever has one row in it. I only have one form and when I use the form editor and then start the Form Navigator I see this - Forms FormSearch FormDetails FormPayments In the above my main form is FormSearch which is linked to the subform FormDetails by the common column Subscriber_ID. The subform FormDetails is itself linked to the subform FormPayments by the common column Subscriber_ID. The FormPayments contains a table called PaymentDetails. This should work flawlessly as follows - A1. Open the form and see the last viewed subscriber details with the subscribers payment details populated in the PaymentDetails table. A2. Select a different subscriber from the drop down box in FormSearch, the contents of the sub form FormDetails changes to reflect the required subscriber and the contents of the PaymentDetails table changes to reflect the currently viewed subscriber's payment details. With 5.0.0.5 I get this - B1. Open the form and see the last viewed subscriber details with the subscribers payment details populated in the PaymentDetails table. Except that the first cell in the table is empty, the rest of the data is correct. B2. Select a different subscriber from the drop down box in FormSearch, the contents of the sub form FormDetails changes to reflect the required subscriber and the contents of the PaymentDetails table changes to reflect the currently viewed subscriber's payment details. Except that the first cell now contains the data from the previously viewed subscriber, i.e. the cell contains the data that should have been displayed in the cell during step B1 above. The rest of the data is correct. Alex
Created attachment 118111 [details] Demonstrates bug 93618
Form appears to work correctly in Version: 4.1.4.2 Build ID: 0a0440ccc0227ad9829de5f46be37cfb6edcf72 OSX 10.10.4 There is no blank first cell in any of the payment detail table grids and the display updates accordingly with the chosen subscriber. With Version: 5.0.0.5 Build ID: 1b1a90865e348b492231e1c451437d7a15bb262b Locale : fr-FR (fr.UTF-8) I can confirm that first cell of table is displayed blank, but _only_the_first_time that the data for that subscriber is called up. In subsequent call ups for the same subscriber, the first cell value is displayed correctly. I can also confirm that the first cell of the grid, when changing the subscriber for the first time only, keeps the data value of the previous subscriber. Confirming : regression
Also works correctly in Version: 4.3.5.2 Build ID: 3a87456aaa6a95c63eea1c1b3201acedf0751bd5
Sounds oddly like a duplicate or recent bug that was fixed by Lionel and which introduced a regression which causes the blanking out of the value in the first cell. As for the repeat display of the cell value of the preceding record in in the first cell, I don't remember whether this was linked or not to the original bug, but I seem to recall it was.
(In reply to Alex Thurgood from comment #4) > Sounds oddly like a duplicate or recent bug that was fixed by Lionel and > which introduced a regression which causes the blanking out of the value in > the first cell. > > > As for the repeat display of the cell value of the preceding record in in > the first cell, I don't remember whether this was linked or not to the > original bug, but I seem to recall it was. I'd be grateful if you could find back this bug, and retest this one with a version where it is fixed.
(In reply to Lionel Elie Mamane from comment #5) > > I'd be grateful if you could find back this bug, and retest this one with a > version where it is fixed. Had a trawl, but no dice, I saw mjayfrancis had bibisected the earlier bug report pointing back to your commit, but damned if I can find it again now...
(In reply to Alex Thurgood from comment #6) > (In reply to Lionel Elie Mamane from comment #5) > > I'd be grateful if you could find back this bug, and retest this one with a > > version where it is fixed. > > > Had a trawl, but no dice, I saw mjayfrancis had bibisected the earlier bug > report pointing back to your commit, but damned if I can find it again now... Bug 92725
In Version: 5.1.0.0.alpha1+ Build ID: ad1f0d1f1a195a00cf2ec2848745fdc6186bfbb1 Locale: fr-FR (fr.UTF-8) I can still reproduce the problem reported here.
Bug 93390 is the bug where mjayfrancis bibisected commit 3b9e66fdcade5a222a9dc99ad74627473b1fd4e7 as altering the behaviour of the display of numeric data in grid controls
Hi, we also have the same problem upgrading to version 5.0.2.2 on Debian Testing. It seems to us that only the date/time cells are affected ... Regards! Guido
(In reply to Alex Kempshall from comment #0) > A2. > Select a different subscriber from the drop down box in FormSearch, I assume you mean "and click the button 'Search Subscriber'". > the contents of the sub form FormDetails changes to reflect the required > subscriber and the contents of the PaymentDetails table changes to reflect > the currently viewed subscriber's payment details. Cannot reproduce in my development tree, in which I just fixed bug 93390. Assuming this is the same bug as bug 93390. If you can reproduce in any future version (released or nightly) where bug 93390 is fixed, please reopen. *** This bug has been marked as a duplicate of bug 93390 ***
Just tried the nightly build - libreoffice-5-0~2015-10-15_00.30.07_LibreOfficeDev_5.0.4.0.0_Linux_x86_rpm.tar.gz the cell is now populated. However, it's populated with the wrong contents. Using the supplied database bug93618. Assuming the last subscriber viewed in a previous session was 730 when stepping through subscribers in the following order the date in the first cell of the payment details should be Subscriber id: Date 730 24/12/13 828 12/12/13 829 10/08/14 830 01/07/13 1339 20/02/14 1340 24/02/14 What I'm seeing is Subscriber id: Date 730 24/12/13 828 24/12/13 829 12/12/13 830 10/08/14 1339 01/07/13 1340 20/02/14 Alex
(In reply to Alex Kempshall from comment #12) > Just tried the nightly build - > > libreoffice-5-0~2015-10-15_00.30.07_LibreOfficeDev_5.0.4.0.0_Linux_x86_rpm. > tar.gz > the cell is now populated. > However, it's populated with the wrong contents. Thanks for testing so fast! That's really helpful. I have a tentative fix. Hope to commit today.
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e6c329cc55af00fec99ada5cac15b2d4752b7474 tdf#93618 teach DbCellControl about "Date"/"Time" as known value property 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.
Did a git pull on master, compiled and tested. Looks good to me. Thanks Alex
Thank you for your feedback, let's put this one to VERIFIED then.
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=de79c5838412a89313777e61c6cdc2ac01f9980a&h=libreoffice-5-0 tdf#93618 teach DbCellControl about "Date"/"Time" as known value property It will be available in 5.0.4. 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-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=2e9e8066d1182e513394749615ae5254b4944e6b&h=libreoffice-5-0-3 tdf#93618 teach DbCellControl about "Date"/"Time" as known value property It will be available in 5.0.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.
Let's simplify a bit
Had similar bug. Tested with 5.0.3 (Comment 18 said it was pushed in 5.0.3) : bug still here Tested with daily (5.0.4dev) : bug fixed Hopefully, it will be in 5.0.4 :)
(In reply to itsupport from comment #20) > Had similar bug. > Tested with 5.0.3 (Comment 18 said it was pushed in 5.0.3) : bug still here > Tested with daily (5.0.4dev) : bug fixed > Hopefully, it will be in 5.0.4 :) Yes, there was a mistake. The fix was put in the 5.0.3 branch, but after 5.0.3 was tagged/compiled, so too late. The fix will definitely be in 5.0.4.
Hi, upgrading to version 5.0.4 on Debian Testing fix the bug. Thank you and regards! Guido