Jump to content

David Poiron

Member
  • Posts

    203
  • Joined

  • Last visited

Posts posted by David Poiron

  1. I'm really struggling with escaping quotes properly. I want to perform some actions on symbols that have a certain record format field, but I cannot seem to get the criteria to work using ForEachObject.

     

    Im using selCriteria:=concat('CPA Products'.'Serial'=,RF1) as the criteria where selCriteria is the selection criteria and RF1 is a string variable for the record format field contents. Because of all the record format quotes, I cannot seem to get it to work no matter how I try to escape them. Any help would be appreciated.

  2. I would like to create a script that replaces the content of an attached record format field in symbol instances that match the currently selected symbol instance. My thought is that this could work in one of two ways:

     

    1. replace the record format field contents in other instances, or

    2. replace the symbol instances entirely with the currently selected symbol instance, all of which are based on the same symbol definition.

     

    Does anyone know of a similar script out there? I have used VS many years ago and am very rusty, but a similar script might get me to the goal faster.

  3. At present we use Filemaker to create all the records and organize them by section number for a particular project and then export that to 24"x36" PDF, which we then reference in Vectorworks. Vectorworks worksheets are not nearly as adaptable graphically as tables are in Filemaker. We do think there is benefit to link the two but there are a number of missing workflows in Vectorworks it seems to make this work for our needs.

  4. We've been using FileMaker Pro to create an in-house database of products but linking it directly to anything in VW is proving to be a challenge. Each of our products has a serial number that we would like to link to objects in VW but we are at a loss of how to do so reliably - we've tried ODBC before but as one VW staffer mentioned to us recently that can be a brittle connection. In addition to the serial number our system has a three letter code for each section of the North American MasterFormat System (as that is easier to read than a bunch of section numbers), followed by a number for the object in that section for that project: say DHW-01 for a door handle for a particular project. The number changes depending on the project but the serial number (a 6 digit number) does not. It would be great to use data tags to extract the information from an object but it is difficult to make links to the extent we would like; even for symbols there does not appear to be a way to assign a serial number to the symbol that is persistent across all instances of the symbol, which is needed to make a link to an outside database. I am curious about the use of VWs Database Manager for this. I would like more information on @shorter s exporting and importing routines if he is willing to share.

  5. I ask for a "survey points file" in CSV format, which is a commas separate value file of all the survey point in a text file. Then it is rather easy to use the "Import Survey File" command to import the points into VW, creating stake objects that can then be made into a site model using the "Site Model From Source Data.." command. You need to specify the type and order of the information for each point: I use ID, Northing, Easting, Elevation, Description/Note. Tell the surveyor what order you want the information. Be careful of survey points that are not at grade. They can be stripped out of the CSV file prior to import or removed after importing.

    • Like 2
  6. We ended up creating a tag for each level and minusing the layer level from each definition in the data tag for levels 2 +. It worked, but there should be a definition for the height of the grid tool relative to the layer as opposed to the origin, so that one tag is sufficient.

  7. We are using the ceiling grid tool and are trying to tag the height of the ceiling grid. We are using the #IPZ# definition to get the height, which works well when the layer elevation (Z value) is zero. When the layer elevation (Z value) is say 10' (as it might be on the second level of the building), it adds 10' to the ceiling height value for the tag. Therefore, a ceiling grid object set to 8' on level 2 shows a tag value of 18' instead of the desired 8'. Is there any way to set up the tag with a different definition, or perhaps subtract the layer elevation to get the desired ceiling height value for each level of the building?

    • Like 1
  8. Strangely enough we have been using a data tag for space objects for reflected ceiling plans, as we need the space label location to change for these drawings. I had a thought that if I had multiline text, my room number which is above the text would need to move upwards automatically. I thought to use a coincident constraint between the two text objects, but this tool does not seem to work on the side, top or bottom centres of text objects, or the centre of the text objects. Do you have any suggestions on how to address this apparent shortcoming?

  9. I think you are saying that there would still more than one data tag but a script would figure out which one is required and place it accordingly? I would not know how to script that but it sounds interesting.

     

    We actually have three tags currently 1. one for "vertical" walls in plan and section 2. one for "horizontal" walls in plan 3. one for roofs and slabs in section.

  10. From a workflow point of view, we are trying to get the same information (reference/mark) from each object (roof face, slab or wall) - we are tagging building assemblies. At this point we need at least two data tags to access what we see as the same type of information from different object types. If the "Current Tag Field Definition" field allowed for some calculations/logic, then we could perhaps add multiple criteria in an if or case statement. Or perhaps a pset can be established that can take the same field across multiple object types - not sure how that works internally. Fire ratings, sound ratings and the like are all fields that we see should be accessible across roof faces, slabs or walls.

     

    Of course I would like to see things happen automatically, but would be curious as to how this could be scripted as a workaround.

  11. For some reason the roof face and slab objects use the slab pset and so I can use one data tag for both those object types. Walls have to be a separate data tag. On another note, I have a difficult time tagging assemblies in section - even when the viewport is set to not show objects beyond, it seems to want to find objects beyond the cut plane instead of objects at the cut plane for some assemblies. Anyone else have this problem? VW 2021 SP2.

  12. @line-weight these are my thoughts exactly. many of our interior walls have different buildups and that buildup often has to change through the design or construction processes. Sometimes you have to simply reverse the sides to place the buildup on the other side of the wall but then currently have to move the wall itself to keep the structure in the same location.

×
×
  • Create New...