Jump to content

Tolu

Vectorworks, Inc Employee
  • Posts

    601
  • Joined

  • Last visited

Everything posted by Tolu

  1. You make valid points; and you are correct (if you go 30 minutes without hitting Ctrl+S) your back up will have the latest information. You will be better off with a backup that is ~3mins old versus a WF that's older.
  2. If it's 3 minutes old in most cases it might not be a problem; but I would advice against it (or say be very careful). Take the following scenario: 1. 12:00pm - You check out "Design Layer-1" 2. 12:01pm - You make some changes on "Design Layer-1" 3. 12:03pm - Backup of WF gets created 4. 12:04pm - You "Close and Release" your WF and you choose to discard all changes At this point, the backup WF thinks it still owns "Design Layer-1" and it has changes on "Design Layer-1" but the PF says it doesn't. This is an over-simplified example, but this is an example where the information in the backup does not correlate with the PF. Now, you will actually get a warning (alert dialog) when you reopen the backup file. Vectorworks will detect some discrepancies like the one mentioned above. Thanks, Tolu
  3. 2. You should always Commit and Refresh into your last saved WF. In the case that you have to recover work from a backup copy of your WF, I recommend you open the backup WF, and copy & paste information from it into your actual WF. Never "Save and Commit" from the backup copy. This is necessary because the WF stores information about which objects you own, and the changes you have made in the WF. Some of this information is also present in the PF. Specifically, the information in the WF must correlate with the information in the PF. The information in a 3-day-old backup WF, for example, will not correlate with the information in the latest version of the PF (well, unless the PF is also 3 days old or the owner of the WF has not done any work in 3 days). 3. "...so being able to override that from another user is handy". Yes, it might be handy but releasing someone else's work means that other person will all lose work (i.e. the work is present in their WF but it cannot commit it into the PF). If 3 people working on the project can perform an admin release, it is difficult to identify what got released and when it was released.
  4. Just wanted to chime on this report: 1. It is recommended that your Working Files (WF) are saved locally. 2. Do not use auto saved backups of your WF with Project Files (PF) . It is best to always reopen the PF to get a new WF. 3. Do not make all users an Administrator. The original poster mentioned all users are administrators. This is dangerous. This means any team member can release the exclusive lock that another user owns on one or more objects. If this happens, that user will lose work. Thanks, Tolu
  5. Hi Lars, If other users are able to access the PF on the server, I suspect it is a permission issue. I would recommend checking the permissions on the PF and its containing folders. You mentioned all users are using a MacOS. Do you know what protocol the affected user is using to connect to the server? Is everyone using the same protocol? Thanks, Tolu
  6. Hi Batch convert only requires one pass; and it should not require 12 hours to convert 32 files. Something is wrong here. In addition, you should not be required to click on any button. Could you please post a screenshot of the dialog to which you are referring? Thanks, Tolu tfapohunda@vectorworks.net
  7. Hi Genie, Could you please send me your files (tfapohunda at vectorworks.net). Regards, Tolu NNA
  8. In the master file, do you see a Record Format named "NNA#3__NNA_Wall_Style_Format"? If you do, delete the format. You should stop getting the message. Regards, Tolu
  9. The eyedropper tool does not work on DLVPs in Vectorworks 2008. This feature was added for Vectorworks 2009. Regards, Tolu
  10. Hi Richard, There are two ways to accomplish what you are trying to do. However, how you want your DLVP to react will determine which method you use. You should be aware of the following two fundamental things: - SLVP can only control local classes/layers (i.e. classes/layers that exist in your drawing or classes/layers you see on the Navigation Palette or Organization dialog). - Similarly, RDLVP (referenced DLVP) can only control referenced classes/layers (i.e. classes/layers that exist in your referenced drawing). Method 1: There is a checkbox control, ?Use current document?s class visibilities?, on the Viewport class properties dialog for RDLVPs. This allows a RDLVP to respond to changes in the visibilities of local classes in the drawing that are also available in the RDLVP (changes made via Nav. Palette or Org. dialog). This setting is per RDVLP. With this checkbox turned on for RDLVPs that are embedded in a SLVP, the class visibilities that you specify in the SLVP will affect embedded RDLVP. Note that with this method, whenever you change the current document class visibilities, your RDLVPs will also change, but they will always look the same when shown embedded in a SLVP. Method 2: You can duplicate your RDLVPs, put each RDLVP on different layers (or assign then to different classes, your choice), and make each RDLVP show/hide the necessary classes. Then on the SLVP side, make each SLVP show/hide the RDLVP based on the layer (or class) that your put them on. Hope that helps. Regards, Tolu NNA
  11. In regards to the huge file size, there is an option not to save reference cache to disk. This will reduce your file size, however, you will be required to update the reference when you open the file. For the slow down, here are a few questions: 1. What version of VW are you running? A detailed signature will be helpful here. 2. What exactly is slow? Reference update speed, DLVP draw speed? Could you please provide details? 3. Does the slow down happen always, frequently, or sometimes? Best Regards, Tolu
  12. I am glad that helped. The "small mountain" means use viewport specific class definition (i.e. the viewport determines the definition of that particular class). The toggled state which gives you the "VW file" icon means use current document's class definition (i.e. the current document determines the definition of that particular class in the Viewport). The "arrow" indicates whether or not to update the class definition (as defined by column 4). All these settings work hand-in-hand. For example, when the "small mountain" is on and the "arrow" is on, this means the class definition is as defined in the viewport's source. I hope that helps. BTW, the help does a better job explaining. Regards, Tolu
  13. Hi David, Thank you very much for the sample files. >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. As I stated in my previous post, because layers from file 1 made it into file 3 does not mean that VW is reading them from file 1. VW will read and use the layers of file 1 that are present in file 2 if it finds that those layers are up to date. Specifically, when you update the reference in ?Untitled 3.vwx?, NNA#1#1_Design Layer-1 is read from ?Untitled 2.vwx?, NOT ?Untitled 1.vwx?. Furthermore, NNA#1#1_Design Layer-1 is an empty in ?Untitled 3.vwx?; therefore it is not a contributing factor to your slow down. As such, if you purge "unused layers" and run the script, you will not see NNA#1#1_Design Layer-1 listed because it would have been deleted because it is empty. I currently unable to determine what is causing your slow downs. If you are still seeing slow downs, I had be glad to take a look at your files and your server configurations. You can also contact tech support. Best Regards, Tolu
  14. Hi David, Please submit a bug report: http://www.nemetschek.net/support/bugsubmit.php You can send the files to: bugsubmit@nemetschek.net Thanks Tolu
  15. What you need to do is make the referenced Design Layer Viewport (DLVP) use the current document's class definition and visibilities. To do this: 1. Select the referenced DLVP 2. Click the "Classes..." button on the OIP to display the "Viewport Class Properties" dialog 3. Select all the classes and toggle on the column after the visibilities. This makes the DLVP use the current document's class definition. You will get a message effectively asking if you want to update the class in the current document to have the same definition as the source document. Click "Yes" to continue. 4. With all the classes still selected, toggle the column before the class names such that the classes are not updated whenever references are updated. 5. Finally, turn on the "Use current document's class visibilities" checkbox to make the DLVP use the current document's class visibilities. Please let me know if that helps. Regards, Tolu
  16. You are referring to the "Use current document's class visibilities" setting for the DLVP. When this is checked, it causes the DLVP to ignore its visibilities and uses the active document's class visibilities which is exactly what you described above. However, Pat is referring to the "Retain Design Layer Viewport class override" checkbox control that is available on the "VP Class Properties" dialog for SLVPs.
  17. Hi David, Besides the suggestion about saving cache, there isn't a setting available that will prevent file 3 from accessing the information from file 1. If you do not want file 3 to access file 1, then make sure that the Design Layer Viewport (DLVP) in file 2 of file 1 is placed on its own layer and that that layer is NOT visible in any DLVP that you create in file 3. >The file 1 information is turned off in the viewport in file 3 How are you accomplishing this? The DLVP in file 3 has no direct access to the information in file 1. >but Vectorworks wastes time and network resources reading it anyway. Again, I am not sure exactly how your files are setup, but because layers from file 1 exists in file 3 does not mean that VW is reading them from file 1. VW will read and use the layers from file 1 that are present in file 2 if it finds that those layers are up to date. In order to correctly determine the slowdown you are seeing, we'll need your files and your server configurations. Thanks, Tolu
  18. Hi David, Could you send me your files or sample files (tfapohunda at vectorworks.net)? Vectorworks should only follow the reference links as I described above.
  19. Hi David, Vectorworks will follow the reference links from file 2 back to file 1 only if the needed information from file 1 is not already present in file 2. If you do not want this, you will have to edit the reference in file 2 and select "Save Reference Cache". This will guarantee that the reference data from file 1 is always saved with file 2. As such, when file 3 attempts to update its reference from file 2, all the needed data from file 1 will always be present in file 2. Let me know if that helps. BTW, what version of Vectorworks are you using? Regards, Tolu
  20. Hi Grant, Please submit a bug report: http://www.nemetschek.net/support/bugsubmit.php You can send the files to: bugsubmit at nemetschek.net Thanks Tolu
  21. Hi, If your references are using "Absolute path" and you change the name of a top level folder, the references will be broken. Is that what you mean by "lost"? However, when you open the file, you should be informed about broken references. My advice is to always use relative path, so you copy/move the top level folder to another computer and your references will still be intact. You can get to this from the Organization dialog -> references tab, select all references, and click "Edit...", and select the "Relative Path" radio button. In regards to viewport settings being lost. Viewport settings are not path based and those reside with each file. So changing the top level folder should not affect/discard any viewport setting. I will be glad to take a look at the files. You can send them to tfapohunda at vectorworks.net Best Regards, Tolu
  22. Hi Steve, Please submit a bug report: http://www.nemetschek.net/support/bugsubmit.php You should also send the files with which you are having problems to: bugsubmit@nemetschek.net Thanks, Tolu Fapohunda NNA Engineer
  23. I am unable to reproduce this. Can you please submit a bug report with the file attached. http://www.nemetschek.net/support/bugsubmit.php You can send the files to: bugsubmit@nemetschek.net
  24. Pete, please submit a bug report with the file(s) included. Submit a bug report: http://www.nemetschek.net/support/bugsubmit.php You can send the files to: bugsubmit@nemetschek.net Tim, if you are using SP3 and you are seeing 'NNA#_' worksheets, please submit a bug report as well.
  25. You are getting that dialog because the active file is set to use DLVP as the referencing system and you are trying to create a reference via the references tab. If you want to use DLVPs as the referencing system, you should create a viewport, otherwise, on the references tab of the organization dialog, click the Settings... button to switch to Layer Import (AKA old style referencing) system. > Why won't it remember that I changed my "settings"? Because the setting is file based. If you want it off in all your new files, you should create a template file.
×
×
  • Create New...