Bug Hunting Session
Bug 93403 - LO Base grid – change DataField name form reload on button pressed event doesn't refresh data
Summary: LO Base grid – change DataField name form reload on button pressed event does...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
4.3.5.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Lionel Elie Mamane
URL:
Whiteboard: target:5.3.0 target:5.2.0.1 target:5.1.4
Keywords: bibisected, bisected, regression
: 99094 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-08-13 07:10 UTC by Stang
Modified: 2016-12-01 08:55 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample DB (13.00 KB, application/vnd.oasis.opendocument.database)
2015-08-13 18:36 UTC, Stang
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stang 2015-08-13 07:10:02 UTC
Using a macro, I want to change the data displayed in a grid column from one table field to a different field of the same table.

This was working fine in version 4.2.8.2 with the following code:

oForm = ThisComponent.Drawpage.Forms.getByName("MainForm") 
oField = oForm.getByName("TestTable")
oColumn = oField.getByName("FormattedField1")
oColumn.DataField = "MONTH3INFO"
oColumn.Label = "MONTH3INFO"
oColumn.Name = "MONTH3INFO"
oForm.Reload()

I recently found out this version was ending its' life cycle so I upgraded to v5.0.0.5 and most of my code works fine except for this particular piece. It is a critical part of the system design and I haven't figured out a way around it.

I receive no errors, the Label, Name and DataField all change properly (used MRI) but the data never changes. However checking BoundField (read only) I see it is still pointing to the previous data field.

I have also gone back and tried v4.4.5.2 and the results were the same.

Finally, I reloaded 4.2.8.2 and again the code worked correctly.
Comment 1 Alex Thurgood 2015-08-13 10:33:50 UTC
Macros not being my forte, I guess we would need to have a same document including the macro code that works in order to be able to test.
Comment 2 Alex Thurgood 2015-08-13 10:34:12 UTC
(In reply to Alex Thurgood from comment #1)
> Macros not being my forte, I guess we would need to have a same document
> including the macro code that works in order to be able to test.

Sample document, apologies for misspelling
Comment 3 Julien Nabet 2015-08-13 11:15:55 UTC
Just a naive question because I don't know too macro part.
According your code, "reload" call would 
1) save data
2) reload per se the form?

I mean, I know you said this code was working before but, could there be a save function to call explicitely before using "reload" here?
Comment 4 Julien Nabet 2015-08-13 12:20:33 UTC
kendy: just noticed http://cgit.freedesktop.org/libreoffice/core/commit/?id=e5ba9090f4809906ffa1c1dea352161cb988b97f, I wonder if this commit could help or if a similar problem could explain the fact the data aren't saved.
(I know it's a long shot but...)
Comment 5 Jan Holesovsky 2015-08-13 12:43:14 UTC
Julien: I am afraid in this case, it would be more interesting to find the root cause; as the Mihai's commit addresses special LibreOffice OnLine needs, and it seems to me that many people are still against having the 'allow save always' as default...
Comment 6 Stang 2015-08-13 18:36:13 UTC
Created attachment 117899 [details]
Sample DB

Very simple form with three buttons. Macro code kept to a minimum.

Self explanatory.

Tested today 8/13/15.

Ver 4.2.8.2 column 2 title changes and data changes with each different button clicked.

Both ver 4.4.5.2 and 5.0.0.5 the column title changes but the data remains the same.

Thank You.
Comment 7 Stang 2015-08-13 19:34:22 UTC
Just download daily build because of a different bug.

In this build

Version: 5.0.2.0.0+
Build ID: aff9057c35827ec7a6219b1c752f7525db64cdca
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:libreoffice-5-0, Time: 2015-08-13_06:15:07
Locale: en-US (en_US.UTF-8)

The data still does not change but in addition now the column heading does not change.
Comment 8 Stang 2015-08-13 19:49:52 UTC
Sorry about Daily Build comment.  Pressing buttons too fast.  Macros were turned off.

Turned macros on.

Column heading changed, data remained unchanged.
Comment 9 Stang 2015-08-13 22:36:28 UTC
While this may not be the best solution, I found a way to make the code work in all versions.


Delete line           oForm.Reload()


Insert the following lines in its' place:

                     oForm.unload()
                     oForm.load()

Form works again in all versions.
Comment 10 Alex Thurgood 2015-08-14 07:12:58 UTC
(In reply to Stang from comment #9)
> While this may not be the best solution, I found a way to make the code work
> in all versions.
> 
> 
> Delete line           oForm.Reload()
> 
> 
Sounds like a regression to me if oForm.Reload() has stopped working...especially seeing as you are already in the parent form.
Comment 11 Alex Thurgood 2015-08-14 07:16:34 UTC
Confirming on 

Version: 5.1.0.0.alpha1+
Build ID: ea29d320754fdb21b336cb78f816b8081371def9
Locale: fr-FR (fr.UTF-8)

OSX 10.10.4

It coud also be related to an absence of on-click event dispatch not working properly, that kind of rings a bell too...
Comment 12 Alex Thurgood 2015-08-14 07:20:41 UTC
Seems similar to bug 91600 with oForm.updateRow
Comment 13 Alex Thurgood 2015-08-14 07:24:46 UTC
Works in 

Version: 4.2.4.2
Build ID: 63150712c6d317d27ce2db16eb94c2f3d7b699f8

OSX 10.10.4
Comment 14 Alex Thurgood 2015-08-14 07:25:35 UTC
Setting version to earliest where problem observed, I tested on 4352 and problem was already there.
Comment 15 Alex Thurgood 2015-08-14 07:33:11 UTC
The only output I see in lldb when loading the form is :

warn:sw:49177:1:sw/inc/swrect.hxx:295: SVRect() without Width or Height
warn:sw:49177:1:sw/inc/swrect.hxx:295: SVRect() without Width or Height

and multiple lines of 

warn:legacy.osl:49177:1:unotools/source/config/moduleoptions.cxx:524: unknown factory


Clicking on the buttons produces no output at all in lldb, which suggests that the code returns 0, but the data sets never get refreshed, even though the column headers change to match the selected button.
Comment 16 Matthew Francis 2015-08-14 09:29:48 UTC
This seems to have begun at the below commit.
I see Lionel is already Cc:'d - could you possibly take a look at this one? Thanks

    commit d4b7e3d12a02d27e9ea569e4828370cf00e17540
    Author:     Lionel Elie Mamane <lionel@mamane.lu>
    AuthorDate: Mon Dec 2 23:44:11 2013 +0100
    Commit:     Lionel Elie Mamane <lionel@mamane.lu>
    CommitDate: Mon Dec 2 23:57:15 2013 +0100
    
        fdo#72163 after updating m_xComposer, command facets are not dirty anymore
    
        Else we dispose m_xComposer too eagerly; still used by m_pCacheSet.
    
        Change-Id: I205488465c19a356534df17b8a5e9a20ce6766c9
Comment 17 Robinson Tryon (qubit) 2015-12-13 11:13:20 UTC Comment hidden (obsolete)
Comment 18 Alberto 2016-04-04 12:20:48 UTC
Hello,

I've noticed that form.reload (inside a macro which must change a query definition in a base file. The result of the query is displayed in a table in a form an the macro launches form.reload) doesn't work also in libreoffice 5.1.1.3 64bit on win7 machine.
I've noticed that also reload button (form toolbar) doesn't work, but if I reoderd the datas the table is regulary updated.

I'm sorry for my terrible english.
Thanks for your help

Alberto
Comment 19 Lionel Elie Mamane 2016-05-27 13:39:02 UTC
(In reply to Matthew Francis from comment #16)
> This seems to have begun at the below commit.
> I see Lionel is already Cc:'d - could you possibly take a look at this one?

Thanks for the pointer, that was helpful.
Comment 20 Commit Notification 2016-05-27 13:52:31 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=51c8d22ec5e4d306f8f64afb355f95a23deb335d

tdf#93403 check for changed DataSource on all Controls on form reload

It will be available in 5.3.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 21 Commit Notification 2016-05-31 09:51:45 UTC
Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "libreoffice-5-2":

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

tdf#93403 check for changed DataSource on all Controls on form reload

It will be available in 5.2.0.1.

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 22 Commit Notification 2016-05-31 15:48:14 UTC
Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "libreoffice-5-1":

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

tdf#93403 check for changed DataSource on all Controls on form reload

It will be available in 5.1.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.
Comment 23 Stang 2016-05-31 16:42:42 UTC
Since I haven't seen a new daily build since 5/26/16 for DEB x86_64, I used the patch and applied to my downloaded source.  The newly compiled version shows the problem to be resolved with the 2 files changed, 13 insertions, 2 deletions.

Looks good.  Thank You.
Comment 24 Stang 2016-08-05 04:37:48 UTC
Final comment - downloaded v5.2 today and verified this is now working again.  Just a quick thank you for the effort to fix.
Comment 25 Alex Thurgood 2016-12-01 08:55:31 UTC
*** Bug 99094 has been marked as a duplicate of this bug. ***