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.
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.
(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
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?
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...)
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...
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.
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.
Sorry about Daily Build comment. Pressing buttons too fast. Macros were turned off. Turned macros on. Column heading changed, data remained unchanged.
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.
(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.
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...
Seems similar to bug 91600 with oForm.updateRow
Works in Version: 4.2.4.2 Build ID: 63150712c6d317d27ce2db16eb94c2f3d7b699f8 OSX 10.10.4
Setting version to earliest where problem observed, I tested on 4352 and problem was already there.
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.
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
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
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
(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.
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.
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.
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.
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.
Final comment - downloaded v5.2 today and verified this is now working again. Just a quick thank you for the effort to fix.
*** Bug 99094 has been marked as a duplicate of this bug. ***