Jump to content

Lighting Device: Determine 'linked' or 'symbol' object class(es)


Recommended Posts

Using Spotlight:

If I add a "USITT_Followspot" and "Light Instr Robe Actor 3" to my drawing, the classes "Lighting-Followspot" and "Lighting-LED" get created.

  • If I hide the "Lighting-LED" class, the Robe Actor 3 is hidden
  • If I hide the "Lighting-Followspot" class, the USITT Followspot is hidden

Yet, both of these objects are in the "None" class!


When walking the document, how can I determine that the "Robe Actor 3" is in fact in the None class and the Lighting-LED class?


I cannot find any reference to the "Lighting-XXX" class at all.


The "VWSymbolDefObj" pointed to by the "Symbol Name" parameter is also in the "None" class.

I've looked through all the named parameters of the object, and none of them mention "Lighting-Followspot" or "Lighting-LED".

Edited by Richard1
Link to comment

You seem to be asking about an object having multiple classes — but that's not the case. Each object can only be assigned to one class.


However, some Vectorworks are containers: groups, symbol definitions, and plug-in objects. In the SDK, you can test if an object is group-like. Objects inside a container can have different classes than the container itself, which is what you observe here. Class visibility of a container will master the visibility of the object in the container, so in your case, hiding the None class will hide the lighting device itself and all the objects contained within it, regardless of those classes. 


As Kevin indicates, when you walk the document, you need to recursively walk each group-like object, and if that object is a symbol, look at the contents of the symbol definition and walk that.


Though perhaps you can share what you are ultimately trying to accomplish. For example, if you are trying to get a list of all classes in the document, there are easier ways to do that.

Link to comment

As Josh and Kevin say, this is just part of the way that "Container" objects (Groups, Symbols, PIOs) work. Since every object has a class, that means that the container has a class and each object inside the container has a class. In order for an object to be visible, the class that the object is in AND the class of any container object(s) that the object is contained by must all be visible.


If you use container objects that contain objects with different classes than the container (this means almost all PIOs) then Active Only as a class option is less than useful.

Link to comment

I'm trying to determine whether or not to export an object.

If the user has hidden the object, then the object should not be exported.


As far as the user can tell, hiding the Lighting-LED class hides the object, but it still reports True to VWObject::IsVisible() - thus an apparently "hidden" object is being exported.



Link to comment

Thanks for the hint.


It appears that I have to walk the tree of the referenced VWSymbolDefObj and check the visibility of each subobject there too. This seems to work.


It is however very confusing - I would expect IsVisible() to return false if all the symbol(s) used by the object are invisible.

Link to comment

There's actually a logical distinction between invisible and empty. If an object is invisible, either via class, layer, or the visibility flag, then it is inaccessible to the user, and all contained elements are invisible. If a container is visible, but all contained elements are hidden, the container is essentially empty, and nothing displays to the user, but it is still actually accessible. 

In the case of a Lighting Device, even if all the elements of the symbol are hidden, the user can still select the object (with select all, for example) and access the data. In addition, labels may still be visible or the 3D component is visible.

The best approach depends on your import target. If you are importing into something that is data/object-aware, like a visualizer, then you would still want to export a Lighting Device where all the contained objects are in hidden classes but the object itself is not hidden. To some extent, you would accept a garbage-in/garbage-out rule here — the user has not chosen to hide the data-holding object, only its display elements.

If you are importing into another drawing system, for example in svg version of the drawing, where you have a one-to-one relationship between drawing elements, then you do want to make sure to walk into every drawing element in the tree and check for visibility.

  • Like 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...