Order of selected objects


The API says that the selection array is not necessarily in the same order as the users selects them. In my limited tests its seems that the selected items are in the order in which they were created no matter how the user selects them.
I working on a script where user can select any number of objects in advance, but I need to know which one he selects first. Is there any way of doing this without requiring 2 selection operations (the first one being limited to one object)?

I prefer simple commands that operate on already selected objects.


You would need to implement a SelectionObserver.

Whenever the onSelectionBulkChange() callback fires, you’d grab an array copy of the selection, and compare it to an internal ordered collection that you build.
You need to alias onSelectionAdded() to the bulk change callback because the engine still calls this when one item is added using the Outliner. (It is supposed to have been fixed to call the bulk callback, but was missed, again.)

Whenever the onSelectionCleared() callback fires, you’d clear your internal collection.

It is a bummer that they decided not to fix the individual add / remove callbacks from the observer, as coders always want to use such callbacks.

Instead we all have to repeat this coding exercise, and waste memory defining classes that all do the same thing.

You might see if Thomas or Andreas have such a class already in their libraries.


A custom selection tool would be easier to do than messing with observers, imo.


Not sure if that is a guaranty in all scenarios though. Probably a reason why that statement was explicitly added to the docs. (Before my time.)

Even if it did have the entities in the order they where added, you have ambiguous scenarios when the user performs selects multiple objects using Select All or selection box select.

That would be one way.

This would be another way - similar to how SketchUp’s Solid Tools do it. I’d go with this solution as you have much more predictable control over a custom tool rather than observers.


Not in TT_Lib I think… though I’m pretty sure I have done that in some of my extensions, normalizing observer callbacks. I’ve been planning to do a set of observer examples to demonstrate common challenges to the observer system as well as normalize quirky callbacks.