…on multiple object selection.
Since it’s a
Join and not
Block for example. How the new POLY- object is supposed to choose which of its child’s attributes to duplicate?
As far as I know, current behavior is the joined object is copying the attributes of the first pre-selected object.
The thinking behind it is when you come back to revise or add, you don’t have to worry about layers since when you’re joining new stuff with the old one it’d inherit the “old” geometry properties. And you don’t have to sit there and click objects in proper order. It’s a QOL thing for me.
Really don’t want to see that as default behavior.
Regardless, inside the edition of any object you have delete/re-create, at least objects that are transformed with (translate/rotate/scale) are triggering the events of deleting and creating.
I don’t know what that means, and I know what you gonna say, but you can easily do this with a simple script. There’s even a method in Rhinoscriptsyntax called
Oh, I forgot you can pre-select one object the drag-select all others and they will match the pre-selected object attributes.
I think the fly in the ointment is depending on how the Rhino file was saved, the geometry order can be reversed.
There is no way to predict accurate what the oldest object is.
Select the one you want to match first, then windows select the rest.
QOL = Quality of Life.
That’s why I asked for a toggle option in Join command. Nowhere I asked for it to be a default.
I don’t want to do anything else (like running scripts so change my layers) if I don’t have to.
You need to stop your “Scripts for everything” crusade.
not really, just think about it, I do not have your problems.
Having to script something doesn’t stop my workflow.
Just a thought.
How? I’ve never encountered it in 10 years.
That’s an extra click in addition to another 1000. So, 1000 + 1000 mouse clicks vs just 1000. This is the scale of work we operate in.
Also, JoinEdge command does exactly what Join doesn’t. The newer object inherits an older object properties. Which works great for us here.
I’m curious how you got these numbers?
Can I get one of your files? I want to take the challenge and see if I can make a script that will save you months of clicking?
Not sharing that here though, in PM only from now on. Cuz of @pascal.
Sometimes you have to fix a lot of part drawings after shitty drafters. And the amount of lines that have to be modified, added etc is fairly large. Extra click adds up to the agony.
Join, uses the first object selected as the source of the attributes. Of course it does not have to contend with pre-selection. With pre-selection, I don’t think there is any useful or predictable order, currently, on Join.
Except, when you run JoinEdge you can box select and magic happens. The older surface gets prio’d.
Join is weird and clunky. It doesn’t allow box selection after you run the command and the newer object gets to dictate the properties.
The workflow right now is: box select, Join, change layer back to what older object was. I’m asking for the latter to disappear.
Yeah… I guess the object list is being iterated in opposite directions. Currently, Saving and reopening a file flips the order of objects in the overall object list - so your thought would not work, yet, though I have heard some chit-chat here about making that different - maintain the order across sessions - I do not know if that is a V7 project though.
go to the appropriate layer before starting the join command then select all without pre-selection.
Most of the times we revise line work that’s in 3 different layers.
Ooph… Actually that doesn’t matter for us, 'cause added (new geometry) is always being added in the current session. Like literally joining happens as geometry gets added.
I really can’t say much without seing a simple example, I’m sure your process can be improved.
Yep, it can. With Join command working like JoinEdge.