U++

Added possible implementation.

Added second version of the patch.
Now, the sorting algorithm uses information about alignment.

Added third version of the patch.

The algorithm is based on second version of the patch, but uses IndexSort2 function, instead of GetSortOrder and additional Array<LayoutItem>. Also I added the check for count of layout items less than two, where sorting is not necessary.

In the end, I have used slightly different code - RectLess needed to be made more tolerating in vertical axis to correctly accomodate labels, which made it non-transitive, hence selection sort used instead. Also, we want only to sort selected items...

OK, based on suggested issue and some initial experience (you would not believe how often I need this :) I have made following changes:

Changed sorting algorithm to bubblesort, this should at least make it stable (IMO does not change the order if it can be interpreted as fine).

Also changed the algorithm to actually collect all items after the cursor item and place cursor to the last item at the end (which IME is what I want to happen).

Miroslav Fidler wrote:

Changed sorting algorithm to bubblesort, this should at least make it stable

Your algorithm(s) doesn't sort following layout (when all items selected (Ctrl + A)):

LAYOUT(TestLayout, 356, 76)
    ITEM(Label, label, SetLabel(t_("Label")).LeftPosZ(324, 28).TopPosZ(4, 16))
    ITEM(DataPusher, data1, LeftPosZ(4, 64).TopPosZ(20, 24))
    ITEM(LineEdit, edit, LeftPosZ(188, 132).TopPosZ(4, 19))
    ITEM(DataPusher, data2, LeftPosZ(4, 64).TopPosZ(48, 24))
END_LAYOUT

Miroslav Fidler wrote:

Also changed the algorithm to actually collect all items after the cursor item and place cursor to the last item at the end (which IME is what I want to happen).

I still consider changing the cursor to different item, than selected one, as an issue (i.e., distraction of user's attention).

I created new patch, which fixes mentioned issues. It also contains the fix for item selection from ArrayCtrl with Ctrl + mouse click.

Well, I understand your concerns, but for my usage scenario (and I have used it 4 times today, saved me about 20 minutes of work) the comparison really needs to be "tolerant", which obviously creates ambiguity, but I rather deal with that (you can e.g. sort by parts) than not to be able to use the function at all.

What problem is there with Ctrl+Mouseclick?

Miroslav Fidler wrote:

the comparison really needs to be "tolerant", which obviously creates ambiguity, but I rather deal with that (you can e.g. sort by parts) than not to be able to use the function at all.

Ok, I understood, that you need this specific function for your work. I also found it useful, but with different algorithm (sorting by top-left position).

Miroslav Fidler wrote:

What problem is there with Ctrl+Mouseclick?

It collects the same items, instead of removing them, when exists (like LayDes::SelectOne method does for graphical representation), which may lead to crash inside of LayDes:SortItems method (e.g. just click many times for the same ArrayCtrl item and try to use "Sort by position" function).

In conclusion, I could suggest to use two algorithms:
1. Sort by position.
2. Sort by top-left position.

I think, there are no need for top-right, bottom-left, bottom-right functions, because the size increases from top to bottom and left to right (like ArrayCtrl item list graphical representation), which is ascending (two dimensional) sorting (with top preference over left position, in this case).

The second patch for r6303 contains the same fixes, but with two functions.

OK, one last try: by making RectLess less tolerant, it sorts your layout too, while retaining ability to sort what I need... Obviously, there still will be some ambiguous cases, but these will by "human eye" ambiguous as well.

Thanks for spotting the ctrl+click bug.

Ok, now the algorithm is able to sort layout(s) for test.
As I understood, changing an item to last cursor position after sort - is intentional feature.

Thanks.