Created attachment 82718 [details] Database with a report Hello Platform: windows 7 64bits & Version: 4.1.0.3 Build ID: 719826cd009b9a1fa43e253db0616288c682826 The labels displayed in some options lists do not match the functionality. It seems that several options are concerned. For example, the "page break" property of a section. Steps to reproduce 1. edit the report of the attached database. This database was created with an earlier version with the "Force New Page" setting ("Nom header" section) set to "none". 2.Select the "Nom header" section to display its properties. Expected Result: "Force new page" = none Actual result: "Force new page" = Before & After Section Below Parameter => Effect None => After section Before => Before & After After => Before Before & After => None This normally worked in 4.0.4 Same disorder for properties "Page header", "Page footer" of a report. May be other options... Severity set to major because the user is leaded to modify the database by specifying parameters to be wrong with another version. Regards Pierre-Yves
I confirm with : - Windows 8 pro 64 bits - LibO 4.1.0.1 build 1b3956717a60d6ac35b133d7b0a0f5eb55e9155 Best regards Marc
I confirm with 4.1.0 rc3 with Windows XP et Ubuntu 12.04.
Have tested it a little bit. With LO 4.1.0.0 beta1 I couldn't start any report - LO crashes immediately. Also couldn't edit. In LO 4.1.0.0 beta2 the reported behavior appears the first time. Have only tested it for the menu "Force new Page" - shows "Before and after Section", where the other versions of LO show "None". Executes "None". All test were made with OpenSUSE 12.3 64bit rpm.
*** Bug 68190 has been marked as a duplicate of this bug. ***
*** Bug 68188 has been marked as a duplicate of this bug. ***
Hi Lionel, could you please have a look. Or Do you know somebody who had changed something there? Isn't only the sorting of functionality and menue-entry, but also the translation, which had been gone ... (https://bugs.freedesktop.org/show_bug.cgi?id=67112)
Stephan? Could you please take a look at this? It looks related to the new unoidl module, which git log tells me is basically your code. So, what happens is that cppuhelper::TypeManager::getByHierarchicalName (this=0x18b6d80, aName="com.sun.star.report.ForceNewPage") returns a descriptor where the constants are not anymore in a strictly increasing order, but offset by two (value 2, 3, 0, 1 instead of value 0, 1, 2, 3) Here is how it gets to unoidl: #0 unoidl::UnoidlProvider::find (this=0x18ad260, name="com.sun.star.report.ForceNewPage", constant=0x7f0e0e6b2b1b) at /home/master/src/libreoffice/workdirs/master/unoidl/source/unoidlprovider.cxx:1239 #1 0x00007f0e37800699 in unoidl::UnoidlProvider::findEntity (this=0x18ad260, name="com.sun.star.report.ForceNewPage") at /home/master/src/libreoffice/workdirs/master/unoidl/source/unoidlprovider.cxx:1209 #2 0x00007f0e377f2fd6 in unoidl::Manager::findEntity (this=0x18b69b0, name="com.sun.star.report.ForceNewPage") at /home/master/src/libreoffice/workdirs/master/unoidl/source/unoidl.cxx:131 #3 0x00007f0e3c13eed6 in cppuhelper::TypeManager::findEntity (this=0x18b6d80, name="com.sun.star.report.ForceNewPage") at /home/master/src/libreoffice/workdirs/master/cppuhelper/source/typemanager.cxx:2376 #4 0x00007f0e3c13b7c8 in cppuhelper::TypeManager::find (this=0x18b6d80, name="com.sun.star.report.ForceNewPage") at /home/master/src/libreoffice/workdirs/master/cppuhelper/source/typemanager.cxx:1919 #5 0x00007f0e3c13bf54 in cppuhelper::TypeManager::getByHierarchicalName (this=0x18b6d80, aName="com.sun.star.report.ForceNewPage") at /home/master/src/libreoffice/workdirs/master/cppuhelper/source/typemanager.cxx:1989 #6 0x00007f0e0e834f88 in pcr::StringRepresentation::initialize (this=0x304d5e0, aArguments=uno::Sequence of length 3 = {...}) at /home/master/src/libreoffice/workdirs/master/extensions/source/propctrlr/stringrepresentation.cxx:246 #7 0x00007f0e3c0ac275 in cppu::OSingleFactoryHelper::createInstanceWithArgumentsAndContext (this=0x377ae68, rArguments=uno::Sequence of length 3 = {...}, xContext=uno::Reference to (cppu::ComponentContext *) 0x3675ce0) at /home/master/src/libreoffice/workdirs/master/cppuhelper/source/factory.cxx:218 *but* pcr::StringRepresentation::convertSimpleToString very much assumes that its m_aConstants and m_aValues are in the same order. m_aValues is in "strictly increasing" order, but m_aConstants comes from cppuhelper::TypeManager::getByHierarchicalName("com.sun.star.report.ForceNewPage")->getConstants() while m_aValues comes from the initialiser of pcr::StringRepresentation (and is in strictly increasing value order). The same holds for pcr::StringRepresentation::convertStringToSimple Here's how the last one is invoked: #0 pcr::StringRepresentation::convertStringToSimple (this=0x3484c10, _rValue="Before & After Section", _ePropertyType=@0x7f0e0e6b31bc: com::sun::star::uno::TypeClass_SHORT) at /home/master/src/libreoffice/workdirs/master/extensions/source/propctrlr/stringrepresentation.cxx:457 #1 0x00007f0e0e834b6f in pcr::StringRepresentation::convertToPropertyValue (this=0x3484c10, ControlValue="Before & After Section", ControlValueType=invalid uno::Type) at /home/master/src/libreoffice/workdirs/master/extensions/source/propctrlr/stringrepresentation.cxx:199 #2 0x00007f0e0f10aa48 in rptui::GeometryHandler::getConstantValue (this=0x2d8a9e0, _bToControlValue=0 '\000', _nResId=30769, _aValue=uno::Any "Before & After Section", _sConstantName="com.sun.star.report.ForceNewPage", PropertyName="ForceNewPage") at /home/master/src/libreoffice/workdirs/master/reportdesign/source/ui/inspection/GeometryHandler.cxx:955 #3 0x00007f0e0f10acd9 in rptui::GeometryHandler::convertToPropertyValue (this=0x2d8a9e0, PropertyName="ForceNewPage", _rControlValue=uno::Any "Before & After Section") at /home/master/src/libreoffice/workdirs/master/reportdesign/source/ui/inspection/GeometryHandler.cxx:968 #4 0x00007f0e0e72230d in pcr::OBrowserListBox::impl_getControlAsPropertyValue (this=0x3849490, _rLine=...) at /home/master/src/libreoffice/workdirs/master/extensions/source/propctrlr/browserlistbox.cxx:955 #5 0x00007f0e0e72287c in pcr::OBrowserListBox::valueChanged (this=0x3849490, _rxControl= uno::Reference to (pcr::OListboxControl *) 0x37b5280) at /home/master/src/libreoffice/workdirs/master/extensions/source/propctrlr/browserlistbox.cxx:1011 #6 0x00007f0e0e71eed8 in pcr::PropertyControlContext_Impl::impl_processEvent_throw (this=0x391f3c0, _rEvent=...) at /home/master/src/libreoffice/workdirs/master/extensions/source/propctrlr/browserlistbox.cxx:337 #7 0x00007f0e0e71ed4b in pcr::PropertyControlContext_Impl::processEvent (this=0x391f3c0, _rEvent=...) at /home/master/src/libreoffice/workdirs/master/extensions/source/propctrlr/browserlistbox.cxx:315 #8 0x00007f0e3c790d86 in comphelper::AsyncEventNotifier::execute (this=0x34db400) at /home/master/src/libreoffice/workdirs/master/comphelper/source/misc/asyncnotification.cxx:221 #9 0x00007f0e3b9d9a58 in salhelper::Thread::run (this=0x34db400) at /home/master/src/libreoffice/workdirs/master/salhelper/source/thread.cxx:40 #10 0x00007f0e3b9d9e2d in osl::threadFunc (param=0x34db410) at /home/master/src/libreoffice/workdirs/master/include/osl/thread.hxx:187 #11 0x00007f0e3e06f79f in osl_thread_start_Impl (pData=0x34d9740) at /home/master/src/libreoffice/workdirs/master/sal/osl/unx/thread.c:251 #12 0x00007f0e3d798e0e in start_thread (arg=0x7f0e0e6b4700) at pthread_create.c:311 #13 0x00007f0e3da9595d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 The m_aValues itself comes from rptui::GeometryHandler::getConstantValue; file reportdesign/source/ui/inspection/GeometryHandler.cxx, starting line 940 (in master): ::std::vector< OUString > aList; tools::StringListResource aRes(ModuleRes(_nResId),aList); uno::Sequence< OUString > aSeq(aList.size()); ::std::copy( aList.begin(), aList.end(), aSeq.getArray() ); which is then passed to com::sun::star::inspection::StringRepresentation::createConstant, which sticks it in the third element of the rArguments argument to stoc_smgr::OServiceManagerWrapper::createInstanceWithArgumentsAndContext which in turns calls cppuhelper::ServiceManager::createInstanceWithArgumentsAndContext which ends up in cppu::OSingleFactoryHelper::createInstanceWithArgumentsAndContext, which passes the arguments array to pcr::StringRepresentation::initialize, which sticks the third element in m_aValues.
Stephan Bergmann committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=def066bb6559e8c77eeb924db1356f9848f5c8a2 fdo#67109: Order of XConstantsTypeDescription.getConstants is unspecified 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.
<http://cgit.freedesktop.org/libreoffice/core/commit/?id=def066bb6559e8c77eeb924db1356f9848f5c8a2> "fdo#67109: Order of XConstantsTypeDescription.getConstants is unspecified": "...it looks like it used to be the order the constants appeared in the .idl file, while now it happens to be the lexicographical order of the constant's names. For all the constant groups in com.sun.star.report the order expected by the code appears to be the order of the constant's numeric values (which happens to coincide with the order of appearance in the .idl files), so explicitly sort them that way." I found no other uses of XConstantsTypeDescription.getConstants on master that made a similar assumption about order.
requested backports to libreoffice-4-1 (<https://gerrit.libreoffice.org/#/c/5512/>) and libreoffice-4-1-1 (<https://gerrit.libreoffice.org/#/c/5513/>)
Stephan Bergmann committed a patch related to this issue. It has been pushed to "libreoffice-4-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=90826f5ee457449d78608e00bf05be412a86faf4&h=libreoffice-4-1 fdo#67109: Order of XConstantsTypeDescription.getConstants is unspecified It will be available in LibreOffice 4.1.2. 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.
Stephan Bergmann committed a patch related to this issue. It has been pushed to "libreoffice-4-1-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6c17704810cbd8b937abaa915ef89c89337f713d&h=libreoffice-4-1-1 fdo#67109: Order of XConstantsTypeDescription.getConstants is unspecified It will be available already in LibreOffice 4.1.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.
Hello WORKSFORME with Version: 4.1.2.1 Build ID: bf15ac65c2167fb1ef3daf3710609d4a4c369a9 Thank you :) Regards Pierre-Yves