Shouldn't _SelObjectsWithHistory select the parents as well?


#1

Shouldn’t it?
I mean, parents are objects with history, aren’t they?

thx, Tobias


(John Brock) #2

There is nothing tagged on the original object. The child objects are the objects that have history dependency references back to the parent objects.
There are SelParents and SelChildren commands that might be helpful to you.


#3

I wish there was a setting for when an object becomes a parent to be able to change its color.


#4

Since there is _SelChildren, Rhino does know if an object is a parent, tagged or not. So in theory _SelObjectsWithHistory would be possible. What is left is philosophical: are parents objects with history or not? I would say yes.

thx, Tobias


(John Brock) #5

If I remember correctly, SelParents find the history dependent objects, builds a list of their referenced parents and selects them.

That said, you can’t inherit anything genetic from your children…


#6

It would be useful to have a SelParentObjects command that would globally select parent objects. Perhaps SelParents could function this way when no child object is preselected, or with a command option (Child=All).
Having the existing SelObjectWithHistory command include parents would vastly diminish it’s usefulness for things like figuring out which of many instances of an object is the parent for the others when you desire to edit the parent.


(Brian Gillespie) #7

@dalelear - is this possible?


#8

I do agree with Tobias that parents have history in the sense that they are part of a history chain, and more tools to better manage that chain would make it easier to preserve and utilize history.
I think a SelParentsAll button could probably be scripted the same way I find them now–run SelObjectsWithHistory, Group, SelParents, then unselect the group. What is harder, and also needed, is a way to select objects which are both children and parents in the middle of a history chain.


(Brian Gillespie) #9

Just realized that Dale Lear is on vacation until next Tuesday.


#10

Mark, this are all very good points


(Dale Lear) #11

It is possible to quickly find all objects that are a “history parent” of some other object in the model. This could be implemented as an option or separate commands.

If the conclusion of this discussion is to add a command or option to select all parent objects, then please put the item as a bug on my list. It will take less than an hour of development time. Discussion about the best way to provide this capability to users, which version it will appear in, documentation, testing, localization and notifying our users are not included in the time estimate.

– Dale Lear


(Pascal Golay) #12

It seems to me an ‘All’ option on SelParents and SelChildren with no preselection might be simplest for users and fit the Rhino Way without adding a new command. SelObjectsWithHistory might then go away.
$.02

-Pascal


(Brian Gillespie) #13

All this should all be prioritized as part of Rhino 6. We’re not adding features to V5, and we’re rapidly approaching the end of the SR cycle for V5, too.


#14

Hi Brian,

So what happens when the SR cycle of V5 is complete and bug reports keep surfacing?


(Brian Gillespie) #15

Hi Yanni,

There’s no such thing as software without bugs - even if we wish there were. But we can fix the most problematic ones.

In this case, we’re seeing a feature request, not a bug report.

Either way, there’s a time at which we decide to focus on Rhino 6, make weekly builds available for testing, and make all our fixes there.

Once our bug tracking database is public, you’ll see just how much we have piled up - the list seems to grow faster than we can keep up with it sometimes! We still receive bug reports about Rhino 4 - the last service release for it was in 2011. If the bug still exists in Rhino 5, we look into it, prioritize it, and sometimes fix it.


#16

@brian No, my question was generic, and surely there is a distinction between bugs and features request.
Turning your focus on a publicly available V6 WIP will be wonderful, simply because you never let us users down, even on early stages.

Thank you Brian !