Does Contents - Reset Sort Order do anything to the model database?

[Richard Freggi]

I'd be curious to know if clicking on a package in project explorer then Contents - Reset Sort Order only changes the way the package contents are displayed or if it changes the order in the model database.  Any idea?  Thanks

[Geert Bellekens]

The gui uses the field tpos to determine in which order to display the elements.
If you reset the order I guess it changes that field to put the elements in alphabetic order.

Geert

[Uffe]

Hey guys,


Just ran some tests on 15.1 on a JET4 database. It's a little bit weird, but just a little bit.

When an element is created, t_object.TPos is null.

When you move one element up/down, TPos is set for all elements located directly within the package. Simple numbering, starting at 1.
When you reset the sort order, TPos is again nulled for all elements.

I'm pretty sure these changes override any locks you might have in place, although I tested without locks enabled.

If you create a new element after setting a sort order, its TPos is null. This is a little odd.
If you then move some old elements in a way that does not affect the new element, the old elements' TPos are updated wrt one another, but the new element's TPos remains null.

Diagrams and packages also have a TPos. The three TPos'es do not affect one another, but otherwise seem to work the same. In other words, the above behaviour is repeated once for diagrams and once for packages.

Changing the sort order of packages does not affect the TPos of the packages in t_object. It makes sense that t_object.TPos is ignored in this case since there is a t_package.TPos.

I haven't tried forcing an update of a package row in t_object to see if it gets reset properly.

The preference Allow Free Sorting seems to have no effect here. It also does not seem to allow you to sort child packages before diagrams, or elements before either. This makes sense since the TPos'es are distinct.


/Uffe

[qwerty]

I had gathered a bit of that weirdness in my Inside book (p. 53).

q.

[Uffe]

I had gathered a bit of that weirdness in my Inside book (p. 53).

Oh sorry mate, didn't mean to deprive you of a sale.

I should add that the "simple numbering starting from 1" is not something that can be relied upon. You do get that when you force the contents to be numbered in a package where they previously weren't, but the TPoses don't get recalculated when you delete an element. So after a while there'll be holes in the sequence.

I also think, but I haven't tested this, that if you move an element up/down and numbering is already in force, EA just switches the TPoses for those two elements and doesn't do anything to the other elements. Seems like the simple solution.

/U

[qwerty]

No sweat. It's just funny how often people have to fid out again how weird this product actually is and always has been. I did not mean to have that Inside book growing in size over time but to see it getting smaller since I though the Sparxians would start working on making their product better. That very first phase was promising. But that's over. Too much tunnel at the end of the light.

q.