David Aynardi
-
Posts
48 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Articles
Marionette
Store
Posts posted by David Aynardi
-
-
I have STANDARD NAMING turned on. I have the worksheet "ClassNameStds" in my drawing. I have the "use standard naming" check box checked and Standard Naming set to point to our office's standard in the spreadsheet. Our office's standard differs from the default: Our version of class "ceiling-main" is called "ceiling_main" (with an underbar, not a hyphen).
Despite the settings in standard naming, windows and doors persist in introducing the class "ceiling-main" and disregarding the correct name which is listed in ClassnameStds.
is this a bug or do the VW window and door tools ignore the "standard name" process?
-
Can I invoke one plug-in object from within another?
I'd like to offer the user a choice of placing either a path or a rectangle object (as the VectorArch "Space tool" does).
Like the VW "Space Tool", when finished I want to end up with a plug-in object which (togheter with other elements) includes a polygon or rectangle which reports its area and perimeter to the object info palette and which can be edited on screen.
I can't find documentation how to do this, (the space tool is locked so I can't see how it works), but I wonder if the ability to call a path or rectangle plug-in from within the plug-in object exists and is a possible solution.
-
Does anyone know how to create an editable closed polygon (with handles) within a plug in object.
The VArchitect "Space" tool is a perfect example of what I want to accomplish.
Clicking on the space tool opens a Mode Bar allowing placement of the "space polygon" by "rectangular" or "poly" mode. The area and perimeter of the resulting polygon is reported in the plug-in object's "Object Info" and vertexes can be added or moved later.
This is awesome, but the script that generates it is locked so I can't see how it is done.
I found a script that generates a rectangle object among the Vectorscript examples on the website, but can't locate an example of a script that generates a polygon like the one in the 'space' tool.
-
We have a number of symbols which include data fields linked to record formats. This gives us a fill-in-the-blanks capability for symbols such as section indicators. Our symbols are maintained in a symbol library file and referenced into the individual drawings using the Resource Browser. Referencing instead of copying the symbols into individual drawings ensures that every drawing has the same version of the symbols and enables central administration of the project-wide information in the symbols (the fill-in blanks are sheet-specific).
Usually this works perfectly but occasionally the data fields in symbols in individual drawings lose their link to the record format. The correct data remains in the format, but does not appear in the symbol. Updating the Workgroup Reference link to the symbol library does not help.
By trial and error we have learned that the links between symbols and record formats can be restored by using the resource browser of the file where the problem is occurring. First we "Break Reference" for the effected symbol. Then we click "edit symbol" to enter the symbol, click anywhere in the symbols graphic then exit the symbol without making any changes. (Entering the symbol definition seems to be necessary to convince VW that something has changed, otherwise the next step has no effect)
Next we use the browser to access the symbol library file, locate the original copy of the symbol, and re-establish the reference. When VW asks if we want to replace the symbol definition in the target file with the newly referenced symbol we click "yes". The link to the record formats is restored and the missing data appears again in the record fields of all of the instances of the symbol already placed in the drawing.
The link between symbols and record data breaks at random, but one pattern we see is that any edit to the original, even if the edit has nothing whatsoever to do with the data fields, often induces this problem.
What is going on? Is there a fix?
We have had this problem for years, with several version of VW, including 2008, running on several different networks and running on Windows and on Macs. Some of our computers run VW service pack 2 others run service pack 3. No difference.
Attached are two files.
Basic Resouces_WAU.vwx is a resource library including several symbol definitions.
Dets_WAU.vwx is a drawing file which uses symbols referenced from the resource library.
The titleblock of this drawing is a good example of the problem discussed in this post. Any change to the original symbol in "Basic Resoucres_WAU.vwx" even if it has nothing whatsoever to do with the data fields, will disrupt the titleblock in "Dets_WAU.vwx". The damage can be repaired as described above, with no loss of the data in the record formats.
-
Thank you for confirming our suspicion that there is no way to prevent VW from wasting time trying to find information from remote files that is turned off in the DLVP.
This should be fixed in future versions of VW.
To help explain the problem I've attached four files:
Untitled1.vwx
Untitled2.vwx includes a DLVP looking at file 1. This viewport is located on a separate layer so that it can be turned off in file 3
Untitled3.vwx includes a DLVP looking at file 2, with the layer containing the file 1 information turned off in the viewport.
Untitled3.vwx also contains a utility script that writes a list of the layers contained in the file. the output of this utility is the attached file:
file3layers.txt
This shows that Untitled3.vwx contains 5 layers
The first two are the layers actually in the file and reported in the VectorWorks layer menu.
1:1 Design Layer-1
1:1 Ref 3-2
The next two are the layers brought in from file 2 by the design layer viewport. Although the utility script reports these, they do not show in the VectorWorks layer menu.
1:1 NNA#1_Design Layer-2
1:1 NNA#1_Ref 1-2
And the last one is the layer from file 1, brought in by the viewport EVEN THOUGH THE VIEW OF FILE 1 IS TURNED OFF!
1:1 NNA#1#1_Design Layer-1
On our large projects, Vectorworks bogs down on these "invisible" layers. In our project files the VectorWorks Class-Layer Mapping tool flashes a message box stating that the file contains "over 500 files". The Class-Layer Mapping tool is seeing the cumulative total of layers in all of the turned-off viewports throughout the project. This is confirmed by my layer list utility. (I posted the output for one of these projects on this message thread a few weeks back).
This should not be occurring. VectorWorks should give us the ability to prevent VW from hunting for information more than one link away. When I turn something off I want it really off, not just not displayed.
-
Can the setting "print pattern fill at screen resolution" be un-checked as a default. I want to always print pattern fill at full resolution NOT screen resolution and find that I must remember to un-check the box every time. This shouldn't be necessary. Is there a way to set this the way we want it, then forget about it?
-
I am happy to send a copy of the files if you think this will help, but I don't think that it is necessary. My question is about VectorWorks generally, not about my particular files.
I do not intend to use the file 1 information in file 3. The file 1 information is turned off in the viewport in file 3 but Vectorworks wastes time and network resources reading it anyway. I want to prevent this.
Can VW be prevented from attempting to read referenced information more than one step away? In file 3, I want to read information from file 2. I don't want information from file 1. I don't want to help VW read the information (by caching it in 2) I want to prevent VW from trying to read it. Can this be done?
If after this clarification, you still want to look at the files, let me know, I'll send them on.
-
The file "Room Finish Library.txt" grows every time I open the "Assign Room Finishes" palette to change the wall finishes assigned to a room. What is going on? I'm not going anywhere near the "Edit Finishes" button.
Initially I had a single new finish added to the bottom of the finish list. Each time I open the palette to select another wall finish, I find another copy of the last line appended to the bottom of the list.
-
This is what I am already doing.
One master grid file referenced by all floor plans. But I also want to reference floor plan 1 from floor plan 2 without floor plan 2 seeing the grid file referenced in plan 1. I have the grids turned off in the link between plans 2 and 1, but can't prevent VW from reading the grid info even though it is turned off and not displayed.
Is there a way to keep VW from reading reference links beyond the first generation?
-
Do you mean that there is no way to reference a common grid file (file 1) from each of my plan files without sacrificing the ability of the plan file 3 to reference plan file 2?
I am not attempting to display a reference of a reference. The problematic reference layer in the link between file 3 and 2 is turned off and is exactly the reference I am trying to break. My question is: Even though the layer is turned off and not displayed, VW still reads the data. Can I prevent VW from reading this turned-off layer?
-
What is the purpose of the Auto-classing check box in the Standard names palette under "Document Settings"?
What is the purpose of the three worksheets "ClassNameStds", "LayerNameStds", and "ViewNameStds"?
Is it safe to delete any or all of these from a drawing?
-
Is it possible to reference wall styles?
I have file 1 and file 2.
File 1 includes a wall style defined in the resource browser.
File 2 references the wall style from file 1 and contains walls which use this wall style.
If I open file 1 without closing file 2, edit the wall style and save file 1, I can then refresh the reference link in file 2 causing the referenced file definition to update and triggering an update of the walls that use the style.
If I update the style definition in file 1 and save it while file 2 is closed, I find that I can not open file 2 and that attempting to do so crashes VectorWorks.
I am using VW 2008.
-
Thanks for your suggestion. Unfortunately, this does not address my concern.
I don't want file 3 to read file 1 information under any circumstances, whether or not the information is cached in file 2.
I have the file 1 layers turned off in the reference view-port between 3 and 2, but this does not prevent 3 from reading the layers even though they are not displayed. I want to prevent this.
-
I'm looking for a way to prevent VW from checking every reference link in a set of linked files and to restrict the update to the "last generation" only of reference links.
When VW opens a file, it updates the information referenced from other files then follows the links attached to those files in a progressively growing regression. On a large project this takes an inordinate amount of time, network traffic, and memory space. I want to prevent VW from updating beyond the first generation of links.
This is not the same as preventing automatic updates. It makes no difference if the update is initiated automatically or manually, I am looking for control over the depth of the update, not the timing.
To restate this in detail:
Assume 3 files:
File 1 includes graphic information.
File 2 includes a design layer viewport which references file 1.
File 3 includes a design layer viewport which references file 2.
When file 3 is opened, in addition to updating the referenced information from file 2 VW also follows the reference links from file 2 back to file 1 and updates this "indirect" information as well. This ensures that file 3 is not cut off from the latest version of the info from file 1 even when file 2 has not been opened or updated.
Is there a way to restrict VW to review only the last generation of reference links without pursuing the chain to increasingly remote drawing files? (When file 3 is opened, read only the direct links from file 2, do not pursue the links from 2 back to 1).
-
The reason I got interested in this (other than the long load times we have experienced) is that the VW layer/class map utility flashes a warning when run in some of our drawings, telling us that the file contains over 500 layers.
My layer-list script confirmed the "over 500 layers" that the class/layer map objected to. These layers are not actually in the drawing but are the product of the snowball effect discussed above.
-
Jeff.
I tried the approach you suggest. This prevents automatic updating but does not restrict updating to the last generation of reference files when the link is finally updated manually. You still end up with the big snowball of redundant referenced layers.
Following are two layer lists. First is the layer list immediately after purging unused layers. The first 3 layers are actually in the file. The ones starting nna# are referenced from the top tier of reference files.
A109 Low roof R1.vwx contains 14 layers
///
1:1 1:1 Titlebock
1:96 Bkgnds
1:96 Roof Plan
1:96 Grids
1:96 NNA#19_Grid: Lvls 6-8
1:96 NNA#19_Property
1:96 NNA#19_Grid: Lvl 5
1:96 NNA#21_Lower Roof
1:96 NNA#21#17_Grid: Lvls 6-8
1:96 NNA#21_Area ID
1:96 NNA#21_GRIDS roof
1:96 NNA#21_Penthouses
1:1 NNA#19_1:1 Titlebock
1:96 NNA#19_Grid: Lvls 1-4
And here is the list after manually updating a single refrence file (The link was not updated automaticly because file was set as you suggested).
A109 Low roof R1.vwx contains 54 layers
///
1:1 1:1 Titlebock
1:96 Bkgnds
1:96 Roof Plan
1:96 Grids
1:96 NNA#19_Grid: Lvls 6-8
1:96 NNA#21_Lower Roof
1:96 NNA#21#17_Grid: Lvls 6-8
1:96 NNA#21_Area ID
1:96 NNA#21_GRIDS roof
1:96 NNA#21_Upper Roof
1:96 NNA#21_Grids 6-8
1:96 NNA#21_Penthouses
1:96 NNA#21#16_Lvl 6a, 7a, 8a
1:96 NNA#21#16_Lvl 6, 7, 8
1:96 NNA#21#16_Stairs Lvl 8a
1:96 NNA#21#16_Stairs Lvl 6
1:96 NNA#21#16_Stairs Lvl 7
1:96 NNA#21#16_Stairs Lvl 6a, 7a
1:96 NNA#21#16_Stairs Lvl 8
1:96 NNA#21_Lvl 8
1:96 NNA#21#17_Property
1:96 NNA#21#17_Grid: Lvl 5
1:1 NNA#21#9_1:1 Titlebock
1:96 NNA#21#9_1/8" symbols
1:48 NNA#21#9_1/4" symbols
1:96 NNA#21#16_Lvl 1
1:96 NNA#21#16_Grids 6-8
1:96 NNA#21#16_Lvl 6 area ID
1:96 NNA#21#16_Lvl 6A area ID
1:96 NNA#21#16_Lvl 7 area ID
1:96 NNA#21#16_Lvl 7A area ID
1:96 NNA#21#16_Lvl 8 area ID
1:96 NNA#21#16_Lvl 8A area ID
1:96 NNA#21#16#10_Grid: Lvls 1-4
1:96 NNA#21#16#10_Property
1:96 NNA#21#16#10_Grid: Lvls 6-8
1:96 NNA#21#16#10_Grid: Lvl 5
1:96 NNA#21#16#16_Lvl 1
1:96 NNA#21#16#16_Area ID
1:96 NNA#21#16#16_Grids 1-4
1:96 NNA#21#16#16#10_Grid: Lvls 1-4
1:96 NNA#21#16#16#10_Grid: Lvls 6-8
1:96 NNA#21#16#16#10_Grid: Lvl 5
1:1 NNA#21#16#10_1:1 Titlebock
1:1 NNA#21#16#9_1:1 Titlebock
1:96 NNA#21#16#9_1/8" symbols
1:48 NNA#21#16#9_1/4" symbols
1:1 NNA#21#17_1:1 Titlebock
1:96 NNA#21#17_Grid: Lvls 1-4
1:96 NNA#21#16#16#10_Property
1:1 NNA#21#16#16#9_1:1 Titlebock
1:96 NNA#21#16#16#9_1/8" symbols
1:48 NNA#21#16#16#9_1/4" symbols
1:1 NNA#21#16#16#10_1:1 Titlebock
As you can see, the same layers are listed redundantly, once for each appearance they make in successive referenced files. This is what I'm trying to avoid.
-
Assume 3 files:
File 2 includes a design layer viewport which references file 1.
File 3 includes a design layer viewport which references file 2.
It appears that when file 3 is opened, in addition to updating the referenced information from file 2 VW also follows the refence links from file 2 back to file 1 and updates this "indirect" information as well. This ensures that file 3 is not cut off from the latest version of the info from file 1 even when file 2 has not been opened or updated.
Is there a way to restrict VW to review only the last generation of reference links without pursuing the chain to increasingly remote drawing files? (When file 3 is opened, read only the direct links from file 2, do not pursue the links from 2 back to 1)
On large projects we experience unacceptabe wait times as the software traces out all the reference links, many of which are turned off and not relevant to the drawing we are trying to open. This could be avoided if we could limit the search to only the last generation of linked files. If we need information from a more remote file, we prefer to manually establish direct links without passing information through intermediate files.
-
I'm bringing this up again to keep it near the top of the list. We need to be able to move, crop, and rotate reference file attachments. Lack of this capability is a serious liability for Vectorworks. We have waited for years, time now to fix the problem. Please let us know if this is finally in the works for an upgrade to VW.
-
I just posted a reply to the origninal message in this thread. Then I realized that this has been under discussion since '02. Comon guys, this is taking too long! Please fix the X-ref gap!
V-Works, what's the hold up? Is this technically difficult or is it entangled in patent issues or what?
-
This is to add my vote for improved reference file capability.
Lack of real reference file capability is the single biggest liability in Vectorworks. We need to ability to move, rotate, scale and clip reference attachments.
Viewports are nice, but don't address the same need. We've limped along about as far as we can without addressing the lack of real reference file capability. I hope this deficiency can be addressed in the next edition of V-works.
-
We need a way to locate reference files in the directory tree relative to the location of the drawing, without retracing the complete hierarchy of the server's directory structure. As things now sit, if we ever relocate our project on the server, even if we make no changes to files and directories within the project, we are forced to relink all of the reference attachments by hand. Very awkward.
At least it would be helpful to have a way to do a global edit on the directory structure (ie change the root directory) without being forced to edit each individual reference attachment.
-
Back in May there was a thread on this forum concerning Screen Line Thickness. This discussed an issue that bothers me, but didn't quite arrive where I'd like to go.
I think the zoom line thickness feature is almost, but not quite, all right. I'd like to add a way to tweak the displayed line widths to exaggerate the difference between line weights on the screen without messing up the way they print. Maybe my monitor is badly synchronized with my printer, or maybe my old eyes are going, but I spend too much time zooming in to evaluate the relative weight of lines.
I'm suggesting a control similar to the "advanced controls" for view-ports which applies a multiplier to the actual (printed)line width to arrive at an adjusted "screen width".
-
All classes and levels are turned on.
Occasionally refreshing the display works, not often and in some drawings never.
-
We have a titleblock symbol in one file (source file) x-refed to a second file (target file). The symbol appears in the resource browser of the target file in italics. Clicking on it activates it, an instance can be placed in the target file. This instance remains linked to the source, when the symbol is revised in the source, the revision appears in the target when the x-ref is refreshed.
But..... Sometimes the x-refed symbol fails to appear when the target is opened. This only occurs in certain files, other target files using the same source have no problem. When the x-ref is refreshed manually, the symbol usually appears. Strangely, when the symbol is invisible, it can be selected by dragging across the empty space in the drawing (the handles appear but not the symbol).
Other symbols in the same source file linked in the same way to the same target file work perfectly, appear when file is opened, only the titleblock is problematic.
Elements of the titleblock symbol are placed on several classes. Is this a potential problem? (If this is a problem, why does it work some of the time (all of the time in some drawings))
Possible fix?
Ceiling-main does not respond to Standard Naming!
in Architecture
Posted
Two follow-up comments.
1. The Vectorworks documentation claims that Standard Naming allows the classes created by the door and window tool to be selected from the options in the ClassNameStds shipped with Vectorworks. Although included in the translation table, ceiling-main does not respond to standard naming. It will not translate to any of the alternative naming conventions shipped with Vectorworks (Such as AIA) or to our office's customized standard. Is this a bug? Is the documentation erroneous?
2. Why we want to use "Standard Naming" is beside the point. Either it works as advertised or it doesn't. Does it work? If not, is there a fix?