Peter Vandewalle

I think your formula should be ...S=‘drop-down-menu’... N is for an object name, S for a symbol definition name. And you’ll need to have an instance of the symbol in the drawing. Then, maybe, it’ll work.

You took the words right out of my mouth... 🙂

I do this pretty often. You should just edit the database formula and replace the field content string in that formula with the cell reference.

BuildResourceList should do the trick. I don’t know the type number by heart but you’ll find it in the developers site appendix...

Not linked to an object, I don’t think so. Pretty sure.

You can do that by setting the layer scale for 1 layer and selecting the "all layers" checkbox... Or do you have another reason to script this?

In top plan view the components aren’t visible really. You see a graphic representation of the slab with all visible elements drawn in top view with the attributes as indicated in the style, not the components. If you want to get a correct drawing of a slab, for a lot of reasons, you need to draw 2 slabs: one with the constructive floor, spreading over the whole surface of the building. And a bunch of “finish” slabs per space. That way you can have separate floor finish types per room. And it will also allow you to do as you like.

Worksheet scripting should allow that. I think Julian had some scripts that work both ways.

Since wall, slab or roof components are not objects, you can NOT list them in a database row. Not based on components and not by any other criteria. The only solution to show a database row of components in a layer is by using a database row script.

Try undocking the object info palet from your interface. In a previous version there was an issue with docked object info pallets on Mac. I had a user this week where undocking the palet solved the freezing issues. I also reported this to tech support.

In older versions, one could open the dialog and close it without modifications. At that time the databaseformula was editable in the formula bar. This still works in 2021 also. I've been using that for years. That enhancement request exists indeed. Not sure about how high this is in the ranking though.

@B Cox Hatches aren't necessarily an issue in imports. If you import the file in the correct way, it will be no problem. The issue is that most ACAD-users never fill out the used units in their file, so chances are the units recognised are wrong. Here's the best way to import a dwg-file: Open a new, empty drawing with your drawing units set. (The issue with wrong sized dwg-imports isn't scale related, it's unit related.) Import the dwg-file without using the automatic unit recognition. Start from the idea that the ACAD user is using your own units, so select your own units. After the import, verify the size of any object of which you know a size. Don't trust those things that look like dimensions, often they are groups of lines and texts. While you see the size of the object, try to determine the units in which it has been thought. I.e. if I see a stair in my drawing in cm that says it is '900' wide, I know that should be mm, not cm. This way I'm sure the ACAD-user has been thinking in mm. DO NOT scale all the imported objects, this will cause the hatches issue. Instead of scaling the contents, just close your vwx-file without saving. Open a new vwx-file with your units set. Import the dwg-file for the second time. Now choose the units you derived from the previous import. The import will be OK. Hatches will no longer be an issue.

I use these commands in a 'renovation tool' that is included in our regional version. That tool will show/hide classes depending on a calculation from the class name. So it it perfectly possible.

At creation dimensions will be created in the dimensions class, if that option is checked in the preferences. They can be assigned to any other class manually or by script however. If I get it right you want every text and callout to be assigned to the 'Tekst' class. Not section lines, dimensions, ... Then this script should do the trick: def main(): criteria="INSYMBOL & INVIEWPORT & ((T=TEXT)|(PON='Callout'))" vs.ForEachObject(DoIt, criteria) def DoIt(h): vs.SetClass(h, "Tekst") vs.ResetObject(h) main() Scripts run from the resource browser don't need the 'import vs' line. You don't need to create a selection to pass to the ForEachObject call, you can use the selection criteria.

Also check the density of imported hatches. If you import an acad file and the content isn’t in the correct size, most users will scale the imported objects. The hatches however won’t scale and might be extremely dense. This results in zones with hundreds of thousands of hatch lines that have to be computed by the graphics card. This will dramatically slow down the file.