shorter

Yes they do, and so do we, or rather ours are split by line type, pen thickness, and level of detail.

I do indeed.

Is this style name still hard-coded? This is causing problems. Looks at the Dormitory project example files. They don't use the 'family' name for the Type Name. I have a Door Type, A-B-C. I only want to show 'C' in the Type column. It's unique ID is 'D' so I want the Type Name in the Component table to be 'C' and the Component Name to be 'C-D'.

... is to be like Vectorworks. I like AutoCAD's new icon on the Mac! 😉 2023

Since 2020 it has been possible to show the file's primary area unit and a secondary area unit in a data tag when associated to a space and round to the nearest whole unit. Great for showing sqm (or m2), and sqft concurrently, to the nearest m2 or sqft. However, pre-2020, was this even possible? We could show a 'formula' in the space label, but the Data Tag was quite limited and did not even give the option to show units. Did any one have a solution to this or this is yet another reason why everyone should upgrade to VW2023!

ps Apologies to @Chris Clymer I have hijacked your post!

All workarounds are just that, and generally workarounds take more time, and usually involve 3-4x more steps to achieve the same thing. We need to come up with a script that does some of these things, without the need to create additional layers or classes unless created on the fly by the scripts. Phases are above classes. Layers is close but a phase is more like meta data. The door in the door class, is on the ground floor layer. It is not longer active in terms of geometry but present in terms of data.

I wouldn't have thought so. This exercise was merely to get a useable 2D output from a VW model or imported IFC where no 2D data was forthcoming from the author of the model. Importing an unstructured, chaotic autocad file (you know the sort of thing you usually get from an autocad user...) is a huge problem. Importing a DWG from Revit can be a huge problem. In most cases the 'problem' is created by the issuer not checking or caring what they send you.

Repeatable in what sense?

It still creates a hole in the wall if you just turn the class off, doesn’t it? the door would have to be dragged out of the wall first, so yes, I suppose a class would do it but it’s not quite what I had in mind. it’s more that we need a record of the door but not the door itself to remain in the file.

It's on my list of things to wish for, yes. We should see this incorporated into the software in about 12 years, if class filters is anything to go by... 😉

i.e. show the hatch grey when making the class grey? that would be quite neat if you could.

As @E|FA suggests, use tags in place of integrated tags and they are also, or tend to be, much faster. Space Tags especially. Get above 100 spaces and it really slows down with space labels. Tags are also really easy to make yourself, and you can tag nearly everything once you can work out where the data lives. The only frustrating thing is the incremental numbering. It works on a 'first-come-first-placed' method, so if you do not place doors and windows in a specific order (and let's face it, who does?), the numbering goes a bit crazy. The other thing I don't like about tags (integrated or otherwise) and the BIM methodology generally compared to how we used to tag doors, is that should you delete a door, the tag goes with it, so you can't record why the door number was retired or the door omitted, e.g. for VE. There should be a way to retire a door via a 'phase' that removes it from the wall, but leaves it in the schedule.

We have a received an IFC. It's a monster once imported. It's a 1:1 model. Nuts, Washers, Bolts... even window gaskets. Someone clearly hasn't heard of LOD. We need some sections through the model for detailing purposes. Because the model is huge, there is no way we can federate it with our model take sections through it and use it live. So, we have asked for 2D DWG sections from the author, all nicely coordinated with our 2D detail sections (that are NOT drawn in viewport annotation because we like to coordinate our details...) which in turn are coordinated (i.e, they drop in WITHOUT MOVING THEM), with our model and the design team models. However, because they (and my client) do not understand concepts like 'validation' they refuse to issue DWG and expect us to take the sections outselves. Now the issue here is two-fold. 1 We have to assume that VW is importing the IFC correctly. It seems to but who would know? 2 We have to generate the DWG section and again who knows if it is what the issuer intended. So, with gay abandon, we extract the section as a viewport on a design layer, and 'convert [the viewport] to lines'. Stuff goes missing. We try 'convert to polygons'. Weird things start to happen where triangulation in the model rears it's ugly head. And don't get me started on what happens when you 'Convert to Group'... So we export the design layer as a DWG, and re-import the DWG, and it's... perfect! It's a really lightweight file, and we save loads of time not having to wait for the viewport to update! The question is 'Why?'. Why must we go through this rigmarole to get a clean or complete 2D section from a section viewport of an albeit overly complicated IFC model? Because You 'should' be able to convert to lines or convert to polygons and bang!

Data Tags may be two-step but are far superior to the integrated tag. You can, for example, place multiple tags at once and auto-number the windows. You can put the tags on a separate design layer, which helps to overcome the problem of 'annotation conflict'. Tags can also pick up [almost] anything in the door or window way beyond the data found within the door or window data.

Have you tried using a data tag instead of the integrated tag?

Current behaviour… you can reference using layer import or you can reference using design layer viewport while you can create a design layer viewport from a referenced layer you cannot create a ‘referenced’ design layer viewport at the same time as using layer import referencing both methods have been around since 2009? both have been independent isn’t it about time the two co-existed? then we can do what Revit and autoCAD do

Then it is probably something that has been done in Revit that isn’t compatible with ifc geometry. this happens in vw too and you have to model with ifc in mind not just the native software. for example we can build a 3D symbol insert it into a wall and flip it. No problem for vw. No problem for ifc. Big problem for Revit. bIM is not about sending someone a file and hoping for the best. It is about understanding what works and what doesn’t in the recipient software and build that into your bim standards and protocols you cannot simply point at the ifc and say the ifc is fine it must be you as some software vendors have done for too many years.

Exactly. if using a worksheet best limit the search to the specific door type. if you want the schedule to say ‘ID001’ in one column but only once and then list all the door numbers in another column this is not possible. ID001 will list in every cell.

Should be possible. search criteria in the schedule should be limited to the door type. Right click on the grey header row and edit criteria and set the search accordingly

You mean if they import the ifc into Revit or ArchiCAD it is complete?

You asked where I put notes on a door schedule… I use a data tag.

Is this a one-way trip that you then intend to continue in Vectorworks using the ArchiCAD model as a background, or are you taking over the modelling? Or do you merely need to exchange models and data with an ArchiCAD user, or to federate and then pass on as one model via IFC? If the former, import ArchiCAD IFC, convert to solids, and edit as VW model, adding your elements using VIM* objects or start again and model natively in VIM. * Vectorworks Information Modelling... If the latter, use VIM and import the IFC to coordinate and issue IFC in return. All this of course would be unnecessary if there was a native nemetschek file format that ruled them all.

Data Tag...

I would concur with @jeff prince Set up a elevational viewport of the doors placed in a design layer. Easy, controllable, graphically better. It all depends on what you expect though. Our schedules show the door in plan, section, and elevation, plus detail on a separate sheet to the tabulated schedule detailing size, location, type, etc, so images on a worksheet would never be used. We need to export the drawing of the door as DWG too. Never tried to export a DWG containing a sheet with images but I suspect it won't.