Jump to content
  • 1

Default Class?

Bruce Kieffer


7 answers to this question

Recommended Posts

  • 0

There are several of these peppered throughout VW (“none” and “dimension” most commonly encountered). I usually rename the class then populate according to whatever I’m trying to do. BUT if you rename a default class then pull in other resources that ship from VW libraries, those will automatically repopulate the default classes you renamed. EG if you rename the “None” class to “Something” and pull in a new resource, the default “None” class will repopulate (I don’t recommend renaming the None class).


You might be able to work around this with specific cabinet class by opening the resource drawing itself, renaming the class and saving as a new resource drawing in your user folder. 

  • Like 1
Link to comment
  • 0

I had renamed the none class. I have no idea why I would have done that. I found the "real" renamed none class, renamed that none, and all seems good now. Honestly, I think it would be best to not rename the none class. I can imagine a mess of bad things happening.

Edited by Bruce Kieffer
  • Like 3
Link to comment
  • 0

Ahhh! So are those classes which auto generate when certain vwx PIO  objects are created also “default” classes. Eg Ceiling Main, and Site/DTM/Modifier, etc?  They have secret super powers which affect other objects or visibilities. But a user created class of same name does not exhibit the powers.  I’m not aware of special powers of the None Class, but strange (and glad) to hear success by @Bruce Kieffer in swapping the “None” name to a different class with no deleterious effect. 


  • Like 2
Link to comment
  • 0

Some of the classes that come in with PIOs, like Ceiling-Main, are just the way they've been drawn according to VW convention, I'm unsure as to whether they need to be specifically named that way in order to interoperate functionally with other objects. For instance, you can rename the Site Modifiers class and it will still communicate geometry to the site model. Attempting to delete a class is a surefire way to figure out whether it is a default class or not. The logic of the None class baffles me.


In simplified code terms, I'm not sure if an object is coded <newObject class="none"> under the hood or just <newObject> and we see the None class so we can toggle objects without classes on and off. 


But the hidden classes can be a real pain, and I'm not sure VW has fully rounded out customizability for every single one. I like to attach numbered prefixes to classes so I can easily filter and reduce clutter through the drafting process, but still randomly get VW-specific hidden classes popping up, even when using custom resources in my user folder (Plant-Component-Polygon is currently the one driving me bananas). My only solution so far has been to be more disciplined in reaching for user defaults first, or just suffering through the extra classes until its time to clean up the drawing and moving or renaming them like I want. It would be nice to have one of those coffee breaks cover how to resolve this.

Link to comment
  • 0

I think currently it is not a good idea to fight against VW default Classes.

Some mentioned the fun overwriting the "non" Class.


But as I hate to have thrown in VW default Classes from time to time

conflicting my holy custom Class Standard ....

(Some even do pretty serious things not recognized by their names at all)


I asked for a reliable way to control this since I started with VW 2014 !


I saw customizations meant for VW localizations. Not really open for users.

But e.g. the VW german localization's "none" Class is called "keine" !

(And if you open a german file in VW US or vice versa, you will get both Classes !?)




So I think there would be (reliable) options.


So I always asked for an XML File, that,

when copied from App Folder into user or Workgroup Folder,

contains default Class Lists, e. g. in a way that Text Editor savy experienced users

could edit to their needs, e.g. :


VW US default Class : "glazing-clear" // Class to define standard glazing parts of PIOs//

= LOCALIZED Class (DE : "Glas");(FR : "Verre transparente"); ....

= VW SUPERUSER custom Class Naming - if! overwritten on purpose : (GLAS_KLAR)

So VW internally can and should deal with all imperial named Terms they want,
but let users define or overwrite them as pleased, just read those config files - if aplicable/
available - and use the for display and exports.

Just like a UUID vs a user assigned Object Name.
Maybe that could even prevent from typical "same name" conflicts in VW.
If Names are treated as :


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.

Answer this question...

×   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...