Entity.visible? vs entity.hidden?
-
I think this is one major issue with the SU structure and APIs. There's no way to backtrace. I think you would actually have to build a full tree list of the entities to be able to traverse backwards like this.
-
@thomthom said:
I think this is one major issue with the SU structure and APIs. There's no way to backtrace. I think you would actually have to build a full tree list of the entities to be able to traverse backwards like this.
OK - thanks thomthom.
Everyone else - forget most of this thread - except the original question"
@unknownuser said:
is entity.hidden? the same as !entity.visible (notice the ! sign)
And therefore should I save time and keystrokes by only using one of them?
I believe they both refer the the hidden state, and have nothing to do with layer visibility.
-
I understood that [probably wrongly]...
An object ishidden
if its set to be 'hidden' - i.e. not to be seen.
An object isvisible
if it is on layer that's switched 'on'... ? -
@al hart said:
I believe they both refer the the hidden state, and have nothing to do with layer visibility.
http://forums.sketchucation.com/viewtopic.php?f=180&t=23806#p202821
-
You are right [as thomthom said]
entity.hidden?
is the same as!entity.visible
You can also toggleentity.hidden=true/false
andentity.visible=false/true
-
@al hart said:
both refer the the hidden state, and have nothing to do with layer visibility.
Any reason not to declare
visible?
a bug? -
@martinrinehart said:
@al hart said:
both refer the the hidden state, and have nothing to do with layer visibility.
Any reason not to declare
visible?
a bug?I think the reply you would get is "By design".
From the manual on
Drawingelement.visible=
:@unknownuser said:
This method performs an opposite function to the hidden= method.
http://code.google.com/apis/sketchup/docs/ourdoc/drawingelement.html#visible=
I think a feature request for a different method that will return to whether the entity can be seen in the model or not is what we'd need to make.
Drawingelement.seen?
maybe? And more importantly, a method that will let us dig down backwards in the hierarchy of the entity tree. -
@martinrinehart said:
Any reason not to declare
visible?
a bug?Yeah, because maybe its actually hidden? that's a bug
Ruby likes to have duplicate methods for the same process. Seems like many methods are available in the positive and negative form.
Chris
-
@chris fullmer said:
Ruby likes to have duplicate methods for the same process. Seems like many methods are available in the positive and negative form.
Except that hidden and visible are real attributes of objects, and should not have been used as aliases. Using visible as an alias for not hidden is crap. Leave the sugar out of the API.
-
@thomthom said:
@martinrinehart said:
Any reason not to declare
visible?
a bug?At this point, if they some changed what it meant, it would break any scripts which were using it to mean "not hidden".
However, it would be nice if they added 1 to 3 of these new functions:
entity.is_visible? - not hidden, and not on a layer which is hidden (including groups and sub-components which are hidden or on layers which are hidden)
entity.is_in_current_view - is_visible? and also is visible in current camera view
entity.is_obstructed - is visible? but is behind something else which is not transparent.The last two are pie-in-the-sky, but the first one would be a useful function.
However, as I write this I see that part of the problem is what is meant by an entity. As I drill down through the database and think I am pointed at a single, unqiue entity, I am often pointed to an entity in a component definition, which, if the component is used more than once may be in hidden instances of the same component, instances of the component which are on layers which are off, as well as in an instance which is visible.
What is needed here is a entity identifier which include the "path" to get to the entity, so it truly represents a single unique entity in terms of the display.
-
@al hart said:
entity.is_in_current_view - is_visible? and also is visible in current camera view
entity.is_obstructed - is visible? but is behind something else which is not transparent.I think I would like at least these two to be part of the view object, and pass in an entity, not on the entity itself.
-
It seems visible? and !hidden? are not the same...
I've attached model. visible?==!hidden? for all entities except the deepest one.
Here is log from my Ruby window:m=Sketchup.active_model #<Sketchup::Model:0xb2ce678> m.entities[0].definition.entities[0].definition.visible? true m.entities[0].definition.entities[0].definition.hidden? true
and from my observation visible? is closer to the truth
-
You are testing the definition - definitions are not placed in the model and therefore can't be visible or hidden. ComponentInstances are what you need to test against.
-
@thomthom said:
You are testing the definition - definitions are not placed in the model and therefore can't be visible or hidden. ComponentInstances are what you need to test against.
Thanks for this remark, I'll adjust my code.
Since ComponentDefinition is inherited from Drawingelement, calling visible? and hidden? seems not to be some incorrect operation leading to undefined behaviour. Yes, they may not represent actual state of geometry, but this shows that visible? is not the same as !hidden? at least at implementation level, and thus can it be safely assumed that they are the same in all other cases?
-
@maxim1000 said:
Since ComponentDefinition is inherited from Drawingelement, calling visible? and hidden? seems not to be some incorrect operation leading to undefined behaviour. Yes, they may not represent actual state of geometry, but this shows that visible? is not the same as !hidden? at least at implementation level, and thus can it be safely assumed that they are the same in all other cases?
@unknownuser said:
The visible= method is used to set the visible status for an element. This method performs an opposite function to the hidden= method.
Might be that the
definition
class causes an abnormality. Testing against any other DrawingElement derived class that actually is placed in the model they behave as expects. Though it is odd it should return true on both fordefinition
.
In practice - they do refer to the same thing though.
Advertisement