does selection order ever matter?

paul_1

so far, it seems that all operations that take more than one selected entity work the same, no matter in which order i do the selection.  can i rely on that?  the one exception i've seen is mirroring, and there are big on-screen prompts to tell me what to select first.

ilya_baran

There are some subtler places where it matters.  For instance, if you're doing a Boolean union of "Part X" and "Part Y", if you select "Part Y" first, the result will be called "Part Y" and retain its color (etc.).  Or if you're doing a Transform with "Translate by line" and you select two vertices, the translation will be from the first to the second.  There may be other examples I'm forgetting.

brucebartlett

It does in the slot mate. That's only one I can think of now.

ilya_baran

There are some subtler places where it matters.  For instance, if you're doing a Boolean union of "Part X" and "Part Y", if you select "Part Y" first, the result will be called "Part Y" and retain its color (etc.).  Or if you're doing a Transform with "Translate by line" and you select two vertices, the translation will be from the first to the second.  There may be other examples I'm forgetting.

paul_1

thanks ilya -- in that case, please consider this a feature suggestion:  anywhere order matters should be made

jakeramsley

It also depends what you mean by "matters" which is why it is sometimes hard to disclose that it does.  For instance, when creating a mate, we try to move the first mate connector selected to the second one to help reduce mouse miles and add some consistency.  Does this matter enough for it to be disclosed in the UI?  My opinion is there is a difference where making a successful feature is dependent on the order, such as pin-slot, and that there are potential nuances to selection order.

A couple more selection order dependence that I can think of:
1) Applying batch constraints in sketches apply subsequent picks to the first one picked.  For example, if you selected a bunch of points and wanted them to be horizontal, the horizontal constraints will be applied between the first selected point and all subsequent points.

2) The direction of extrude is dependent on the first selection.  We take the outward facing normal of the first selection as the direction and you can select additional faces that will be extruded in that direction as well.

3) Similarly, the face that the manipulator is attached to in features is on the first one selected.  

4) Three point planes graphically appear about the first point selected.

paul_1

okay, i understand.  maybe these cases don't deserve on-screen prompting.  but subtle effects need to be discoverable -- perhaps these order dependencies could be mentioned (at the level of your comments on your 3 examples) in the mouseover help for the commands.

let me ask one more question, more specifically:  when adding constraints, like "parallel", or "equal", one entity will always move/grow to match the other.  does selection order have an affect here?  i was hoping it would, but it didn't seem to in my test case (which i think ws for one of the point-and-line constraints).  and that got me wondering about the broader question.

jakeramsley

pgf said:

let me ask one more question, more specifically:  when adding constraints, like "parallel", or "equal", one entity will always move/grow to match the other.  does selection order have an affect here?  i was hoping it would, but it didn't seem to in my test case (which i think ws for one of the point-and-line constraints).  and that got me wondering about the broader question.

No it does not.  When you apply a constraint, we send it to our solver and it solves everything in the sketch concurrently.  The solver has no notion of adding A to B or B to A.  It just knows A and B have a constraint and tries to satisfy it.  It tries to move the sketch as little as possible in order to create a solved state.

andrew_troup

Helpful info. Food for thought.

Personally I'm very much in favour of nuances being disclosed, but if they are subtle, perhaps in the Online help, rather than the hovering help?

And (off topic) I would encourage the OnS help writers to be energetic in finding out about limitations, and documenting those, by the time of public launch. Solidworks took a decade too long to work this out, and it was a major PITA experimenting to discover the boundaries of what was able to be done.