Previously selected object access

as we know a command (copy for example) could be run before or after the selection of objects.
I can select some objects by a crossing window in the model and run COPY command or vice versa.
So I need to obtain in RhinoCommon C# the preselected object set in order to handle them in a eventhandler, but I’m cannot figure out how to do it.
Can somebody help me?
Thank you in advance

Hi @luciano.micchini,

The GetObject class is capable of working with pre-selected objects (GetObject.EnablePreSelect), and/or post-selected objects (GetObject.EnablePostSelect). The class can also let you how objects were selected (GetObject.ObjectsWerePreselected).

Is this what you need or are you trying to do something else?

– Dale

Hello Dale,
thanks for you answer. Yes, I have some other questions, indead.
The problem of pre-post selection is, actually, just a part of a wider problem I am trying to solve.
I will try to explain it as easly as possible.
Let’s have a couple of Line segments as in the figure below.


Apparently they are just two simple segments with two coincident vertices in the middle. But, in my case, the black one is a simple line obtained with the standard Line command of Rhino. The red one is a custom object (i.e. a Pipe in a plant or a Wall in a buiding) with a UserData object appended to the Attributes property.
I would like to give the user the possibility to add segments to the custom entity by means of the Rhino Join command without being obliged to implement a specific command for this case. This to avoid the proliferation of new commands.
I noticed that this is possible, provided that the custom entity is selected first. In this case the attributes of the custom entity are applied automatically to the bare line and a single custom entity is created having a polilyne shape. That would be perfect.
But, if the bare line is selected first the attributes of the custom object are lost. So the behaviour of Join command is influenced by the order in which the objects are selected. In the case where a window preselection of many entities is performed, the result should be unpredictable.
I thought that if I were able to intercept and sort the selection set before Join is running I could solve the problem.
In my former AutoCad-Autolisp experience I was used to solve such a kind of ploblem by redefining the standard command with a custom command having the same name (in C# jargon: by overriding), and, at the end, calling the base command to achieve the operation. I didn’t find something similar in RhinoCommon.
So I’m trying now to solve the question in a different (and more twisted) way.

protected override LoadReturnCode OnLoad(ref string errorMessage)
        Rhino.Commands.Command.BeginCommand += OnBeginCommand;
        return LoadReturnCode.Success;

   private void OnBeginCommand(object sender, CommandEventArgs e)
        if (e.CommandEnglishName == "Join")
            RhinoApp.RunScript("!", false);

First I subscribe an event handler in Command.BeginCommand event and when the program enters the handler I test the command name. If the command name is Join I run my function to do the join operation, asking the user for the selection set, sorting it, and perform the join by means of the Curve.Join(…) method. When the program comes back from the custom function I break the command to interrupt the prompt sequence of the standard command. The procedure works well, but I have not implemented the MyJoinFunction() yet: I guess it will be a quite boring job and before undertaking it I would be glad to know your opinion.

Bye Dale, and thanks a lot.

Hi @luciano.micchini,

Thanks for the explanation - this helps a lot. Rather than try to work around Rhino’s behavior, you should just write your own version of Join.

– Dale

:joy::joy::joy:concise and effective, as usual Dale! I think you are right! Thank you!