Created attachment 83114 [details] Sorting of fieldproperties changed from LO 4.0 to LO 4.1 Since 4.1.0.0.beta1 there is a new "sorting" in the properties of a field in a form. I have searched some times to see, that there is nothing new but only changed the old sorting. Don't know, if there is somebody who thought this "sorting" would be better than the old. For me it gives the impression that these sorting isn't changed by somebody, who wants to change the sorting. Seem to be a bug, not a feature.
The list has been placed in alphabetical order. This is not a bug
(In reply to comment #1) > The list has been placed in alphabetical order. This is not a bug I don't know, what you mean with alphabetical order: Nearly at the top of the list I see "Visible". "Anchor" is nearly at the bottom. There is no order in English. OK, my Desktop runs under German language. Lets see: Second entrance is "Hintergrundfarbe". Last entrance is "Breite". There isn't any visible order in this properties. An alphabethical order wouldn't work, when there is no function, which sorts the properties in the right way of different languages. Please have a look at the attachment. I will reopen this bug-report.
I viewed your attachment again . The screen shot was presented in English and if you notice under the general tab. The list goes from A-Z -- alignment being the first and background color being next. This is called alphabetical order from A-Z I checked under releases 4.1.03 and 4.1.04 Window and Linux. They are setup the same way.
(In reply to comment #3) > I viewed your attachment again . The screen shot was presented in English > and if you notice under the general tab. The list goes from A-Z -- alignment > being the first and background color being next. This is called > alphabetical order from A-Z > > I checked under releases 4.1.03 and 4.1.04 Window and Linux. They are setup > the same way. You have had a look at the first two words. But read a little bit more. There is no order! The 7th is "Visible" The 8th is "Enabled" After "Tabstop" follows "Additional Information". I have never heard about a software with menues ordered in an alphabethical order. Don't know, if you are working with databases. But it make no sense, when there appears the Anchor of a box at the bottom of the list, the Hight nearly at the top, the Width at the end and the Position in the middle. The order of such entries must be logical, not alpabethical.
Created attachment 83156 [details] German Property List In thist Screen-Shot you will see, its neither alphabetical nor logical assorted.
confirming Regression ..
additional comments, user is requesting the property fields be group by relevance as with release 4.0.*
I can confirm the regression. This is a bug (no enhancement). IMHO the logical sorting must be (again)
[CONFIRM] with Version: 4.2.0.0.alpha0+ Build ID: d798d26bc4b7572ed10d6baf5aef7382269d7da5 TinderBox: Win-x86@6-debug, Branch:master, Time: 2013-07-29_00:38:14
seems http://cgit.freedesktop.org/libreoffice/core/commit/?id=ca0600f0c9022d631317423ab5a59493b41906ab is the cause of that. cc'ing stephan who knows about this change
So "The difference is that old indices were before calling std::sort in OPropertyInfoService::getPropertyInfo() while new ones are after, but that should probably be OK per the documentation of com.sun.star.inspection.XObjectInspectionModel.getPropertyOrderIndex (which appears to be the only client of that functionality)." was apparently a wrong assumption, and the elements of aPropertyInfos in OPropertyInfoService::getPropertyInfo (extensions/source/propctrlr/formmetadata.cxx) shall have a predefined order after all (thought the original code that established the order would only have worked by luck).
To reproduce: > <noelp> sberg, ok, in a calc doc for example, enabled the 'form' control toolbar, get it into design mode, select TextBox ( that's the one at least mentioned in the bug ) right click and select control from ctx menu then general tab, > <noelp> s/enabled/enable > <noelp> sberg, and of course draw a textbox on the sheet, then " right click " the textbox on the sheet etc.
Stephan Bergmann committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a6fe1fde409ff1accdea49ff9de69658de1e6f5f fdo#67430 Keep original order of entry positions, not alphabetically sorted 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.
requested backport of fix to libreoffice-4-1 towards LO 4.1.1 at <https://gerrit.libreoffice.org/#/c/5215/>
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=b23a866a93e42467ef42c2d46735e1ffcf6f1c78&h=libreoffice-4-1 fdo#67430 Keep original order of entry positions, not alphabetically sorted It will be available 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.