Worksheet Criteria: INVIEWPORT

[ccroft]

As per this and earlier discussions: http://techboard.vectorworks.net/ubbthreads/ubbthreads.php?ubb=showflat&Number=121414#Post121414

If this is implemented, please ensure that it does not affect groups as well.

BTW, what do people use "Including components of: Viewport Annotations" for?

I just noticed that this is in fact INVIEWPORT. Is it broken?

[Pat Stanford]

There are probably cases where you would use the INVIEWPORT command would be used in a worksheet, but it is more likely to be used in a vectorscript. An example would be where you want to go through and change the font of every text block to a different font. In a vectorscript you could set the criteria for the font to change and use the INVIEWPORT to also change things in the annotation.

[ccroft]

That makes sense Pat, but why is it listed as an option in the database criteria editor where we really need it to deal with entire viewports and not just the annotations?

What might be in a viewport annotation that one would wish to report on in a database worksheet?

Everything else you see there makes ultimate sense. It's great to have control over components of symbols and plugin objects, but why viewport annotations?

And here's something. I just opened 11.5 by accident to check on exactly what is and isn't listed in the criteria editor and low and behold in that version it says 'Viewports' instead of 'Viewport Annotations' as listed in 09.

More evidence to make me wonder if INVIEWPORT might be broken

I'll have to check later on to see if it solves double reporting in that version.

[ccroft]

I was playing around with databases and viewports in 11.5 and I realized that this is only about design layer viewports. Something that everyone else probably already knows.

Neither 11.5 or '09 will report on objects that are viewported to a sheet layer unless they are placed as annotations and INVIEWPORT is used. This is good, though maybe not all that useful.

Since 11.5 we've gained the ability to reference external files thru design layer viewports, and obviously we need the ability to report on the objects therein. So far so good.

The trouble is that this is not the only way in which folks use DLVP. They also use them to reference geometry on other layers in the same file, probably for presentation purposes.

So to put a finer point on my wish, what we really need is INDLVP criteria so that we can control the reporting of objects in the viewport, based on whether the viewport is showing geometry that is already in the file or not. Or maybe just a smarter INVIEWPORT that knows not to report on objects in a viewport that are already in the file.

The 'smart' criteria is what is truly needed, because there are those who will have both an externally referenced DLVP and an internally reff'd one, and wish to report only on the objects in the external viewport. Maybe they shouldn't be using design layers for presentation, but that's the beauty of vWorks, right? We invent our own ways of using it.

All these different kinds of layers and viewports are starting to make my head swim....and I'm having a deja vu. I think this whole thing has been spelled out before. Or maybe it's the wine.... I just notice there's 6 spiders on the forum!