Jump to content



Recommended Posts

That's pretty cool...

Even works with opening other VW files.

I'm looking for something that can pick-up the names of the sheet layers in other files (probably searching in one folder) so that a drawing list can be compiled.

VW can now pick up these names and sheets when doing a batch print or pdf. Using something similar, I just want the text or worksheet to be created, showing all the sheets in all the files in one folder.

Does anyone think it is possible?

Link to comment

Give us a very detailed description of what you would like to do.

It would not be to hard to generate a list of everything in a folder, but can you be certain that every VW file in the folder should be included? Can you be sure that every sheet layer in every file should be included? Will there ever need to be exclusions?

Really think through the process and give us the best description of what you really want/need. It is much easier to do the design properly once that to try and go back and add extra stuff later because you forgot some important aspect.

Also, please include a couple of sample files (you can strip most of the geometry out, but please leave the sheet layers and viewports).

After I see what you are really looking for we can see if it is something I can squeeze into my schedule.

Link to comment

Wow Pat!!!

That would be awesome!

Bare in mind that we have a quite large office, and sometimes have individuals working on different portions of a project, and I am trying to create a better work flow and make the best out of VW as I possibly can.

What I wish to achieve is a command/script of some sort (as I do not believe it is possible with worksheets), that would search the sheets in files of a particular (project) folder and display in a worksheet/text box all of the REQUIRED sheets found. The info I would need is:

1. the sheet number (which may or may not include a revision number. eg. A201b)

2. the sheet name

? Note: These variables are separated with a tab space.

This process may need to be reapplied if changes are made to the sheet names, or sheets are added or deleted etc.

A step further could probably use a pre-formatted worksheet to create a drawing list which would just need to be 'recalculated' each time a change is made (or to check for updates). But this is not necessary if it would cause too many issues. For instance, if some jobs are larger than others, and therefore require more sheets, the user may still need to edit/reformat the worksheet: at which point, would an 'update' take it back to it's original format?

Although it would be a dream come through, I may be biting off more than I can chew with THAT specificity! A 'stupid' worksheet (as they say) may be the better option, with MAYBE an initial format that would take a little editing by the user each time it is 'updated'. This worksheet would probably also be duplicated each time it is updated (similar to your PIO List Script).

Here is how we currently (tend to) work in the office...

We have a model file with most of the info/geometry (and what not) that is developed in different stages; Preliminary, Town Planning, Working (Construction) Drawings etc. , and placed in that corresponding folder. My aim for this exercise deals with the final stage (Working Drawings), as the cover sheet that includes a list of all of the drawings (sheets) occurs here.

The main model file would consist of only some sheets, such as the generated SCHEDULES, and I think it best also, to include the SECTIONS in here as well*. The other drawings would be new documents that may reference in the model file and would include various sheets for the particular representation where annotations and other data can be created/edited. I believe that all of the drawings that are issued are given with the same prefix in front of the drawing number (eg. 'A'), and I would therefore only require to pick these up. In short, a way to choose the desired sheets would be cool, but even if a criteria has to be specified, I would be satisfied.

*Creating sections from a referenced file seems to work fine, but there were a few bugs with it the last time I tried. Especially the inability to use class overrides to change the look of certain elements.

At the moment, the Cover Sheet file consists of:

A border

Sometimes an image of the building

The name of the number of the project

The drawing list

The drawing list is manually configured in one or many text boxes laid out in column format to fit the page and is located on the bottom half of the page. The top half is where the building's image would go.

The sheets in the various files would normally use the 'automatic drawing coordination' option and is therefore 'synced' with the custom title block using:

S_Drawing No_SN for the Sheet Number

S_Sheet Title_SD# for the Sheet Title

:rNo, :rDate, :rNote for the (custom) revision info

[by the way; I really love how these things can be customized like this, as well as the tag schema thingy with the ID Label tool (which I will have tried out, and am looking for ways to make it useful for us)!]

A problem I find with the sheet title (using automatic drawing coordination), is when a multi-line title is specified in the title block, the actual name of the sheet layer only shows the first line. Hopefully this can be fixed, as it would help with batch PDFs as well. This is something to keep in mind in order to generate this drawing list.

So, to summarize?

In ONE project folder, in a 'Working Drawings' folder, there are a number of VW Drawing files, each with one or many sheets inside of them. Using 'Automatic Drawing Coordination' and custom title blocks, I wish to locate certain sheets (by choice or by criteria), and place/list them (numerically by sheet number) in a worksheet or text box in a cover sheet document with as little a hassle as possible!

An alternate option I have also thought about, is a script/command that can be run on completion of a particular document, that would send/export the sheet data to the cover sheet document. Maybe this is in a record format of some sort, therefore allowing us to go to the coversheet document and use a pre-formatted worksheet (VA Create Schedule?) to generate the drawing list using the particular criteria in a worksheet. This way, ALL sheet layer info (and not just specific sheets) can be sent, and then organized/sorted in the final stage (in the cover sheet document's drawing list worksheet). However, this would mean that all users would have to remember to run the command, or the one creating the cover sheet must open all the appropriate drawing files and run it.

If this can work, it'll be amazing! Let me know if any further info is required?

In the mean time, I can't wait to see what you can come up with?


Link to comment


Would adding an extra class (invisible) and a bunch of locus points in that class be acceptable? I could basically make a locus point for each "Sheet" with the information regarding that sheet attached. You could then use the standard worksheet tools to generate whatever kind of report you want/need.

What about adding a new layer when the "Harvest" script is run? This would then have all the information about the sheets in the folder in one place and it could start off with the worksheet already populated.



Link to comment

Hi Pat...

Thanks for your reply...

This sounds similar to what I was thinking in my "alternate option", but if I understand it correctly;

Would the only open file need to be the 'Cover Sheet' file, where the script is run from? Or would the script send it TO the 'CoverSheet' file and one would have to manually open each file to run the script?

I totally understand that an object (locus points in this case) would need to be placed in the file to pick up the record info, and that is what I had in mind. So I am totally fine with a class being created, and loci coming in. Am I also to understand that each time the script is run, these loci would come in to a new (different) layer each time creating almost duplicates (of the same loci on different layers), but the new layer is actually 'updated' information? This seems like a really viable method (if it works), and maybe the layers are named by time and date to keep track of them. More than likely we may only require the latest version.

I think I can see how it would work, and am GAME!

Can't wait to try this baby out!

Link to comment
  • 5 weeks later...
  • Vectorworks, Inc Employee
Would adding an extra class (invisible) and a bunch of locus points in that class be acceptable? I could basically make a locus point for each "Sheet" with the information regarding that sheet attached. You could then use the standard worksheet tools to generate whatever kind of report you want/need.

Hi Pat,

I'm a little late on this, but you can also attach a record directly to a layer (and even a class, BTW). No need for loci.

Link to comment
  • Vectorworks, Inc Employee

Hi Farookey,

Yep. Mind you, I have not yet done much with this ability so you'll want to experiment a bit to make sure it works as you'd expect. IOW, use at your own risk. :-)

As for every object in a class automatically having a record attached. No, Think of the class definition as an object that has the record attached. Objects using that class are still different objects with their own records.

There is no way of attaching a record to a layer or class without scripting it. But, commands could be created to allow you to do just that.

Attaching the records (using Vectorscript) works the same way as it does for any other object. As long as you have the handle to the layer or class, you can attach the record.

DISCLAIMER: Like I said, I haven't played around with this much so, anyone that knows or discovers otherwise, please correct me. Oh, and I'm not responsible for anything that could possibly go wrong as a result of doing this. :-P

Link to comment

Thanks Matt.

I was aware of the record to layers and classes.

In this case, since I am bringing data in from another file I thing it is better to use an actual object rather than add to the layer/class structure of the file.

There has to be something to attache the record to.

Actually you could probably make multiple symbol definitions and attach the records to those, but I still think a locus or other object is probably best.

Or maybe use rectangles and create a sheet with a layout giving an approximation of the file/layer/class structure.

Have to think about that and find time.

Link to comment
  • Vectorworks, Inc Employee

Ahh. That's what I get for skimming this thread. I probably need to reread a bunch of things to be more helpful. While I still don't have a complete understanding of what you're trying to do, it sounds like loci would be best for carrying the data, but a symbol might be a great place to store them all in and also serve as a transfer mechanism from file to file.

Link to comment
  • Vectorworks, Inc Employee

Hi Robert,

That's what I thought but I was silly enough to try it anyway. :-)

Try something like this:



SetRecord( GetObject('MyClass'), 'MyRecord' );

SetRField( GetObject('MyClass'), 'MyRecord', 'Field 1', 'This is a test' );


Then this:


Message ( GetRField( GetObject('MyClass'), 'MyRecord', 'Field 1' ) );


Amazingly enough, it works!

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