Description: Creating a new report or working with an old one, the ADD FIELDS dialog no longer allows for fields to be added to a report. Neither by double clicking on a field name in the dialog or by drag drop of the field name onto the report page. Steps to Reproduce: 1. Open any Base file 2. Go to the Reports section and choose 'Create report in design view' 3. Select any table 4. Double click on a field name in the dialog or drag a field name to the report Actual Results: nothing happens Expected Results: the Field and field label are added to the report. Reproducible: Always User Profile Reset: No Additional Info: This was happening in 6.2Alpha earlier (sorry I forgot to enter a bug) but wasn't in 6.1.1 it is now also in 6.1.2
Came across this yesterday with my master 6.2alpha build on MacOS. Additionally, I don't get a "Add Table" window which I thought we had in previous versions, and so I can only choose a table from a dropdown list if the Properties dialog is displayed in the sidebar. Confirming that which ever field I then choose, clicking on Add does nothing... @Drew : do you also see an issue with the background shading of the buttons in field selection window; i.e: they're all offset to the left ?
Created attachment 145261 [details] bibisect in linux-64-6.2 repo : tail of terminal output Working on debian-buster in the linux-64.6.2 bibisect repository, I trace the bug to the range: commit s-h date -------- -------- ------------------- good f224ffcd f8edef39 2018-05-25 10:10:00 bad 34b63425 726d7e7b 2018-05-25 10:59:48 I am setting keyword bibisected.
On pc Debian x86-64 with master sources updated today, I could reproduce this. I noticed this log on console: warn:dbaccess:17523:17523:dbaccess/source/core/dataaccess/ModelImpl.cxx:853: DBG_UNHANDLED_EXCEPTION in static bool dbaccess::ODatabaseModelImpl::commitStorageIfWriteable_ignoreErrors(const com::sun::star::uno::Reference<com::sun::star::embed::XStorage>&) type: com.sun.star.uno.DeploymentException message: component context fails to supply service com.sun.star.io.TempFile of type com.sun.star.io.XTempFile context: cppu::ComponentContext
It fails at https://opengrok.libreoffice.org/xref/core/reportdesign/source/ui/report/ReportController.cxx#3487 3487 uno::Reference< report::XReportComponent> xShapeProp(pObjs[i]->getUnoShape(),uno::UNO_QUERY_THROW); Armin: thought you might be interested in this one.
I'm not sure but think this part may be a start to investigate: #0 0x00007ffff363680b in SdrObjFactory::MakeNewObject(SdrModel&, SdrInventor, unsigned short, tools::Rectangle const*) (rSdrModel=..., nInventor=SdrInventor::ReportDesign, nIdentifier=37, pSnapRect=0x0) at /home/julien/lo/libreoffice/svx/source/svdraw/svdobj.cxx:2985 #1 0x00007ffff3b125ce in FmXFormView::createControlLabelPair(OutputDevice const&, int, int, com::sun::star::uno::Reference<com::sun::star::beans::XPropertySet> const&, com::sun::star::uno::Reference<com::sun::star::util::XNumberFormats> const&, unsigned short, rtl::OUString const&, SdrInventor, unsigned short, SdrPage*, SdrPage*, SdrModel&, SdrUnoObj*&, SdrUnoObj*&) (_rOutDev=..., _nXOffsetMM=2000, _nYOffsetMM=0, _rxField=uno::Reference to (dbaccess::OTableColumnWrapper *) 0x555558fb7b18, _rxNumberFormats= uno::Reference to (SvNumberFormatsObj *) 0x5555585e54b8, _nControlObjectID=39, _rFieldPostfix="", _nInventor=SdrInventor::ReportDesign, _nLabelObjectID=37, _rModel=..., _rpLabel=@0x7fffffff13d0: 0x0, _rpControl=@0x7fffffff13d8: 0x0) at /home/julien/lo/libreoffice/svx/source/form/fmvwimp.cxx:1604 #2 0x00007ffff3b0a1dd in FmFormView::createControlLabelPair(OutputDevice const*, int, int, com::sun::star::uno::Reference<com::sun::star::beans::XPropertySet> const&, com::sun::star::uno::Reference<com::sun::star::util::XNumberFormats> const&, unsigned short, SdrInventor, unsigned short, SdrPage*, SdrPage*, SdrModel&, SdrUnoObj*&, SdrUnoObj*&) (_pOutDev=0x555558c0c0d0, _nXOffsetMM=2000, _nYOffsetMM=0, _rxField=uno::Reference to (dbaccess::OTableColumnWrapper *) 0x555558fb7b18, _rxNumberFormats=uno::Reference to (SvNumberFormatsObj *) 0x5555585e54b8, _nControlObjectID=39, _nInventor=SdrInventor::ReportDesign, _nLabelObjectID=37, _pLabelPage= 0x555558bca880, _pControlPage=0x555558bca880, _rModel=..., _rpLabel=@0x7fffffff13d0: 0x0, _rpControl=@0x7fffffff13d8: 0x0) at /home/julien/lo/libreoffice/svx/source/form/fmview.cxx:571 #3 0x00007fffb26eb597 in rptui::OReportController::addPairControls(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (this=0x5555582053d0, aArgs= uno::Sequence of length 1 = {...}) at /home/julien/lo/libreoffice/reportdesign/source/ui/report/ReportController.cxx:3453
I gave a try with https://gerrit.libreoffice.org/#/c/61146/1 I don't know if it's the right patch but at least it works. Let's wait for Armin's review.
Julien Nabet committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f2bd68c33c13b94cf844227d04a7eba9fe3723f8 tdf#120152: fix adding labels in reportdesign It will be available in 6.2.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.
Tested with Version: 6.2.0.0.alpha1 OpenSUSE 15 64bit rpm Linux Buggy behaviour has been gone there. Could it be also been fixed on LO 6.1?
(In reply to robert from comment #8) > Tested with > Version: 6.2.0.0.alpha1 > OpenSUSE 15 64bit rpm Linux > > Buggy behaviour has been gone there. Could it be also been fixed on LO 6.1? I tried to backport it but had no feedback so abandoned the patch. Have in mind that it badfully brought some regression.
it introduced bug 120782, so we either fix it in a different way or we fix bug 120782 as well. Until we do one or the other, we can't backport it to 6.1...
putting back to NEW for the time being...
Julien Nabet committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/f88b95032262c434647475b6af7e33068635b6c4%5E%21 Revert tdf#120782, tdf#120728, tdf#120152, tdf#120151 It will be available in 6.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Should fail again since I reverted my patch. Indeed, it brought some regression.
Regression introduced by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=4b4942224b550235da228655677b5c068a053254 author Armin Le Grand <Armin.Le.Grand@cib.de> 2018-04-16 22:34:50 +0200 committer Armin Le Grand <Armin.Le.Grand@cib.de> 2018-05-25 12:31:32 +0200 commit 4b4942224b550235da228655677b5c068a053254 (patch) tree a660a04a1f7a3eee910da780ece271d68942201d parent f8edef392245c292398a80f6a858ca19f32df9c3 (diff) SOSAW080: Derive SdrObjGroup from SdrObjList Bisected with: bibisect-linux64-6.2 Adding Cc: to Armin Le Grand
Can reproduce
Fixed with tdf#120728
Verified in Version: 6.2.0.0.alpha1+ Build ID: 4326fb3ef3ddd7c6f9d08ba96add4f4736503ceb CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: threaded @Armin, Thanks for fixing this!!
*** Bug 122026 has been marked as a duplicate of this bug. ***