LLBLGen Pro v5.5 RTM (5.5.1)

The ordering of 'set of elements' fields in a derived model does not make sense to me. All normal fields are sorted alphabetically, but the 'set of elements' fields are out of any order I'm aware of. It's not alphabetically and it would be nice if it follows the same pattern. It's okay that all 'set of elements' fields are placed after all normal fields.

Would this be possible?

Are you talking about the Tree on the left (Sub element Selection) or the one on the right (Shape Editor)?

You can click on column header for sorting, so if you click on "Kind" it should sort everything alphabetically within each kind.

For the window on the right, I find them already alphabetically sorted and grouped by "Kind"

I meant the left (Sub element selection). Yes, I see you can order by Element. But I like the 'default' ordering: Fields first, then 'sets'. On the right I can make that happen per your suggestion, but at the left there is no 'Kind' to order by.

Please check attached screen shot. Maybe you need to widen the view.

Ha thanks, that was it.

But this ordering is not persisted. So I make this change, then opening another derived model reverts to default. And reopening the designer has no effect either.

Could you please persist these settings?

The sorting isn't persisted, correct. You need to keep this sorting for working on the models? For code generation the elements are ordered by name ascending, so they're emitted in the same order every time.

By default, the elements in the UI editor are added sorted by sourcetype, then by name, ascending.

I can understand, but when I'm using this, I'm looking in the names of column Element, as this is my first column, it also has the selection boxes and all, so I see immediately what I'm dealing with. It does not make sense to me to use the name of fields and then not use the name of set and references but to go to column Type to go through that alphabetically. What if I have all hierarchies opened, I'll go nuts.

If you could make the sorting in Derived models as Kind, then Name, then I'll be happy.

It may even be better to have Fields first (as is now) and then Single Elements + Multi-elements after (I see the latter as the same when selecting child fields). So for me Single element reference and multi element sets can be sorted together. You have that now too but as a consequence of sorting by sourcetype. But if that is difficult, then FIelds first, then Single elements and then Multi elements is oke too.

Or a persisted setting would be nice too. Then you can leave it up to the users.

Ah you're talking about the left pane, I thought you were talking about the right pane I indeed see the elements are added to that rather randomly and there's no sorting taking place at all when they're added.

The fields are sorted in the field ordering applied to the fields (which is by default alphabetical). The navigators (which are the single and multi element nodes) aren't sorted. This is a mistake indeed.

I've now added a default sorting to that of Cardinality (so single element before multielement) and then on name alphabetical. As it's random now anyway the change won't have a lot of consequences in people's workflow.

Change is added to v5.6 next build (beta is out now, so this will be in the RTM build of that).

Great! thanks.