Sort order issue?

[Ken Norcross]

I have two example now of elements sorting, where the sort order is a little mixed up. What should be the last item, shows up as the second item.

One example is sorted by Alias and the elements have aliases like 001, 002, 003, …, 013
The element with Alias 013 shows up second in the sort.

The second example is sorted by Keywords, with similar values like 001, 002, 003, …, 007
Again the last element with a value of 007 shows up second in the sort.

If I change the value to nothing, the element now sorts first, which seems reasonable.
If I change the value to 000, the element sorts first, again reasonable.

Any other value, no matter what it is other than spaces or any number of zeroes, will sort second in the list.

I did not search the forum to see if this has been discussed before. It seems that the search results page is blocked by our company firewall.

Edit to add: I am using the 3.4.0.0 beta, and I do not believe that this was happening in 3.3.15.3 which I was using previously

[eadocX Support]

Hi Ken,
I’ve just tried to reproduce this, but with no luck.
I tried:
– Table formatting, sorting on Alias, name, keyword, both normal order and reverse order
– same for inline
…but I’m using a known data source.
Are you sure your data is clean? Are there any strange characters hidden in the data?
Also, do all the items have the same type/stereotype? Maybe that changes something?
Can you send me an XMI with your data? I don’t think I changed anything in the Sorting are for 3.4

[Ken Norcross]

OK, ran across another example today and spent time investigating. Just to see what would happen I flipped the sort order from A-Z and Z-A. The results were not what I expected, and this led me to realize that there are two different stereotypes involved in the elements we are sorting, and the sort is treating it like there are two groups of things to sort.

These are all Activities, with elements that are straight BPMN 2.0 Activities, and then other elements that are a custom MDG stereotype that extends the BPMN 2.0 Activities.

The reporting and sorting is defined at the Activity level in eaDocX, I treat them both the same in the report.

So in the last example we had 7 Activities, 3 plain BPMN and 4 custom MDG Activities.

Activity alias 001, 003, and 006 are plain
Activity alias 002, 004, 005, and 007 are custom

A-Z sort yields 001, 003, 006, 002, 004, 005, 007
Z-A sort yields 006, 003, 001, 007, 005, 004, 002

This is also consistent with the other examples I have run across.

Let me know if you need more detail.

• This reply was modified 10 years, 9 months ago by Ken Norcross.

[Heather Wallace]

I’m not sure how relevant this is to your problem, but we had a lot of trouble with sort order, when things are drawn from different packages. Now we have a workaround of manually setting on the objects at database level the TPos values that EA uses for its “natural” sort order. This works because we have a logical order of packages and a logical order of things within them, so if a package is the 7th package in logical order, we set its TPos to 7 and its first item TPos to 71. It’s working so far, you just need the package contents to stabilise before doing the fix.

[Ken Norcross]

Thanks for the possible workaround, but at first glance it does not seem practical for us, thanks.

[Ken Norcross]

I contructed a simple test case and the problem seems related to element sorting when the list contains multiple stereotypes.

I created an object diagram, dropped 4 Class elements on the surface, and gave them Aliases of 001, 002, 003, 004

Alias 001, 003 => added Stereotype A
Alias 002, 004 => added Stereotype B

Diagram and all elements in one package.

Created a simple report, based on the diagram and all contents.

Created a simple profile for Class elements, print inline, header of Alias and Name, added one atribute of Stereotype to print in an inline table. Set sorting to sort on Alias, A-Z.

Results print in 001, 003, 002, 004 order

• This reply was modified 10 years, 9 months ago by Ken Norcross.

[eadocX Support]

Found it: the routines for grouping of Table- and Inline-formatted elements were subtly different – fixed in 3.4.0.3, now available.

Solution
————
For Inline formatted elements, eaDocX will now print:
– first all the elements with no stereotype, or a stereotype which uses the default formatting for the element type i.e. same as un-stereotyped elements
– then the groups of elements which have stereotype-specific formatting, printed in groups, ordered by their stereotype name.
– in all cases, groups of similarly-formatted elements are sorted using the chosen sort criteria: which is what you wanted in the first place!

Can I just say this is the perfect example of how to get your forum query actioned: your detailed instructions allowed me to reproduce the issue very quickly, and as result the fix was easy to both create and to test.
Well done, and thanks Ken 🙂

[Ken Norcross]

Thanks for the very quick turnaround, I needed this fix today.

Installed and tested in two documents and looks good, thanks.

[Author]

Posts