P Retondo

Katie, I can get VW running okay just by removing my custom workspace from the workspace folder (thanks to others having worked this out the hard way!). Re: customization, I have added one VS tool, "Toggle zoom line pref". I also had to drag the 2d and 3d section tools into my workspace. Otherwise, it's just a number of keyboard shortcut modifications. It would take me an hour to recreate my workspace - I hate to have to do this multiple times in a trial-and-error effort to locate the problem (assuming I could remember all my modifications correctly, which is unlikely!). Is there any way for NNA engineers to and step through the program to find the error? If the .qtr file were a text file, I might be able to tackle this, but since it isn't, I don't think I can make a meaningful effort. There's the VW log in my user/Application Data/Nemetschek/VectorWorks/12 folder, but no error log.

I just sent the following message to bugsubmit. This is related to an issue I read about on this forum (I can't tell you how helpful it was to have read something about similar problems!), but I can't find the thread now. Any news from anyone about a solution to this problem? Here's the report: When I tried opening VW 12.0.1, I suddenly started getting the following message after the splash screen and before the workspace opens: "VectorWorks.exe has generated errors and will be closed by Windows. You will need to restart the program. An error log is being created." VW fails to open, and the computer hangs until I click on "Cancel." Having read about similar problems on the Users' bulletin board, I suspected my customized workspace. I removed that .qtr file (attached to this email) to the desktop, and VW opens fine. When I put the workspace back into it's folder, VW fails to boot, even though a different workspace has been entered as my current workspace. Rebooting my computer does not affect the problem. The file "Copy of Architect.qtr" was created by modifying the standard "Architect.qtr", not by attempting to import a customized workspace from a previous version. I think this is a serious bug, and has something to do with some tool or function or bit of code in the workspace file. I can't tell you what change I may have made in the last day that might have triggered this problem. I can tell you that I have made no changes in the workspace since last successfully booting the program. However, I did have a problem with the program crashing due to attempting to render a Section Viewport in OpenGL. At the time, I thought this was a memory problem, but after I was able to get things working again by changing the rendering setting to Hidden Line, the next day this problem has started to occur. Please take a look at this workspace and see if you can detect what is causing the problem. As it is, I have quite a few keyboard commands that I depend on for productivity that differ from the standard workspace, and I don't know which of the modifications is causing the problem. I can also tell you that sometimes there is an odd blip on the splash screen just after the lines describing the program components ("Fundamentals, Architect, Renderworks") are added. This blip consists of a gray line that flashes across the screen. It does not appear when the program opens normally, it only appears (but not consistently) when my custom workspace is in the "Workspace" folder and the program fails to open. BTW, I can't find the error log - however, my computer hangs when the Program Error window is open, and I have to click on "Cancel" to get the operating system back on line. VW 12.0.1 Win2000 SP4 Dell Dimension 8200 P3 2.0Ghz 785MB RAM Nvidia GeForce 3 Ti200

Good advice from Jan15. Amy, I think your problem has to do with the fact that even if fractions are not displayed in a dimension value, they may still exist in the drawing and you are getting a rounding error: 9 7/16" + 9 7/16" = 18 7/8", but rounding everything VW will tell you 9" + 9" = 19". Seems like it doesn't add up correctly. Remembering back to my early days on VW, one of my biggest problems was not paying attention correctly to the cursor cues, which led to my drawing things inaccurately. Over time, as I learned to actually read those cues (and not look away at the last moment before clicking!!), my accuracy has improved.

Anyone know if the new Windows/Apple-Intel will use the same instruction set as a Pentium processor? Or any other perspective on how VW would run at the machine level on the new Apple?

I've noticed, for the last several versions of VW, that the vast majority of complaints about the program crashing come from Mac users. Does anyone have a perspective on whether this new development would make VW run on a Windows Apple/Intel computer in the same way, technically, as it does on a Windows Dell? (No denials about past performance of Macs, please, unless you check back a few years on this site to quantify the number of complaints!)

Not only is it not obvious, but the manual has no index entry for "right click" or "mouse buttons" or any other word that a user would conceivably look for when seeking how to implement this feature. Many things have improved with VW over the years, but the manual remains sadly inadequate - especially the index! How hard could it be . . .

Go into the workspace editor. The righthand column for menus and tools represents your current workspace. If you expand one of the menus or palettes, on the right you will see an editable list of the keyboard shortcuts (a lot easier than editing a .pgp file, no?!). If a command currently lacks a shortcut, you can add one - the program will prompt you if another command currently uses that shortcut. Note that you can click on alt / shift / cntrl keyboard combinations. There are two sets of "context menus" that control the behavior of the mouse right-click. [ 04-05-2006, 11:36 PM: Message edited by: P Retondo ]

Is everyone saying that the VectorDepot routines written for VW 9 and 10 will work in version 12?

I agree that this capability should be part of VW - it's one of a small handful of things about AutoCAD that works better than VW. I sometimes use the following workaround, though the plug-ins sound like a better way. I place a locus at the reference point I want to use, then duplicate the locus and the object and move them both, dragging using the locus as my snap point. For those who aren't familiar with the AutoCAD capability, this is what we're talking about. Imagine being able to choose an object, click on some point offset from the object, then being able to copy it multiple times with a single click for each copy, reproducing the offset. Say if you wanted to put a circle inside a bunch of squares, duplicating the relationship to a corner of each square.

quote: viewports (VP's), which can ONLY exist on sheet layersPeter, thanks for your help. Like you, I suspect there is some reason viewports couldn't easily be implemented in ordinary layers, so NNA engineers invented a different "type" of layer. I definitely intend to try them out on my first v12 project. [ 04-02-2006, 06:21 PM: Message edited by: P Retondo ]

Peter, thanks, yes you understood my question 2) correctly. I guess I'll have to fool around with "Stack Layers" to find out what is going on there, since I've used the old "align layer views" to get several 3d layers to be viewed from the same 3d standpoint - but not to be rendered the same, which seems to be a feature of Stack Layers. I also understand how Stack Layer views uses the Z value to line things up as layer links did, even though, as I've explained, mine always lined up anyway. (ArchiCAD's system seems better to me - having things at an absolute Z value on different layers, but being able to activate a separate "relative" Z coordinate system, allowing each level to define finish floor as Z'=0 as an alternative system, while not losing the fact that the floor may actually be 20 feet above ground level.) The thing I don't understand about Sheet Layers is why there has to be a special type of layer. Why couldn't we have viewports without Sheet Layers? In previous versions, you could put different views and scales on a sheet by activating several layers, but the thing lacking was the ability to crop or clip a layer link. This is something new and important with viewports, and it's a plus to be able to set a viewport scale and get rid of multiple layers with different scales. The rest I don't quite get.

I bought VW 12 last year, but just got around to implementing the upgrade from 10.5. After a couple of days' work, and poking around with the new features, I have to compliment VW engineers and developers for paying attention to users' suggestions! There are so many improvements it would be tedious to list them. As a user since MiniCAD 4.0, I would recommend the upgrade. One of the things I tried immediately was to offset a polyline containing arcs - the new polyline also contained the appropriately scaled arcs instead of a thousand corner vertices! Great! I've also noted that adding 2D surfaces has implemented the deletion of unnecessary vertices more reliably (if only this algorithm could be added to the clip tool to eliminate co-linear vertices!). I'm sure there are a multitude of other subtle but important improvements. It's great to see that this company cares and puts time into things that don't necessarily create marketing bling. I'm adding a couple of questions to this post in the hopes that someone could help me understand a couple of things that have changed: 1) I skipped VW11 - can anyone give me a concise explanation of what Sheet Layers will do for me? 2) Layer Z setting - I've tried this feature in the past, but I found that it was ultimately disappointing, so I continue to construct layers at different heights using the true height from zero. Why - because Layer Z was only operative when layers were displayed as layer links. So if I copied a few elements from floor 2 onto floor 1, they didn't carry their intended Z position with them. In a complex model, it's sometimes necessary to resort to this because the whole layer, displayed via layer link, gets too confusing to navigate. Does anyone have a perspective on the new "Stack Layers" mode? Is this any different from the old "Align Layer Views", and does it resolve my lingering aversion to using the Z variable when setting up layers? [ 04-02-2006, 06:07 PM: Message edited by: P Retondo ]

A typical double-acting door has one leaf, not two as in the VW PIO. These "saloon doors" are a relatively uncommon item in my practice, at least. So this is a request that a single-leaf double-acting door be made part of the door PIO, and that the door and hinge axis be located correctly - i.e., the door is centered in the jamb, and the hinge axis is centered on the door leaf and half a door thickness + from the jamb surface.

The door PIOs are currently constructed in such a way that the hinge axis is at the corner of the jamb. Try setting a door to open 170 degrees to see the physical problem that would occur if hinges were built this way in the real world! Could NNA possibly look into placing the door hinge axis where it actually would be - about 1/4" from the corner of the TRIM or casing. Then our door swings would accurately show the actual path of the door, and the door wouldn't appear to confict with the casing when shown at angles greater than 90 degrees. Thanks for listening!

.pdf conversion is different from other image creation procedures. It is based on printer driver conversion, so you need to "plot" the drawing as a .pdf to create the .pdf file you want. Look under your printer choices to find the "Adobe pdf" driver. When you "print," you will be asked where you want to save your file.

I'd just like to comment that Viper X has described with great clarity evidence of a memory leak, Paul from NNA has recognized that and will look into it in a way that seems to promise a solution - what an endorsement for this board and the responsiveness of the VW engineers!

I've been doing a lot of .pdf translation lately. One of the difficulties with VW is that (in my version at least, 10.5.1), pattern fills are inconsistently scaled in a .pdf. It seems to depend on the taget dpi of the output, and always comes out "too small," compared to plotter output. If this has not been fixed in the latest version, I hope in the near future someone will take a look at the way Acrobat is translating VW fills. [ 10-24-2005, 10:26 PM: Message edited by: P Retondo ]

Grant, thanks, that was the key. I thought I had tested lower resolution output by editing my "standard" file settings to 300 dpi, but apparently it only works to modify the resolution in the "Paper/Quality - Advanced" tab. The default was 1200 dpi - by changing that down to 600 dpi, I could output a .pdf successfully. [ 10-10-2005, 01:57 AM: Message edited by: P Retondo ]

jan15, thanks for the feedback and the intelligent suggestion. I'll give pdf995 another shot.

Apparently the larger sized formats have given some difficulty when converting to .pdf's in the past. Only with Acrobat version 7.0 has it worked well with AutoCAD, and Acrobat seems to have worked together with Autodesk to make this happen. Version 7.0 is advertised as supporting conversion of AutoCAD drawings. From where I sit, it would seem that VW has some work to do to make Acrobat work properly, at least on the PC platform. The shareware alanmac refers to looks like a good idea, but when I downloaded it I couldn't find a convenient .pdf markup set of tools - we do that a lot to process shop drawing submittals. I still haven't heard from anyone on the PC platform about their experiences with Acrobat - has anyone seen and (hopefully?) solved the problems I described above? By the way, we use .pdf's not only to send files to be output for drawings sets, and for transmittals to contractora and consultants - we also use them to archive the drawing set at various stages of a project. The .pdf's are unaffected by changes in workgroup references (xrefs in ACAD world), and take up little memory on the hard drive.

I have been able to output up to an Architectural C sheet without a problem. D size doesn't work. I can .pdf the full sheet on a B format at 50%, perfectly. The workaround I'm currently using for D sheets is to output a plot file using a plotter driver, and convert to .pdf using Acrobat Distiller.

Has anyone mastered getting reliable pdf files from VW drawings? We use .pdf regularly to send files from AutoCAD - works pretty much without a hitch. But on VW (using Acrobat Professional 7.0), I get the following problems: Text does not print at all My title block doesn't print Drawing bounds are shifted from the on-screen representation of the sheet Other than that, a lot of elements do show up. I've had success with 8.5 x 11 drawings, but on architectural sheets it doesn't work. VW 10.5.1 Win 2k 768 MB RAM [ 10-06-2005, 08:01 PM: Message edited by: P Retondo ]

ayelet, you should upgrade to v 10.5.1. It's free from the VW website. If that doesn't solve your problem, you might want to check a couple of things: what is the speed of your processor and amount of RAM? Do you have multiple layers visible with Layer options set to "Show/Snap" or "Show/Snap/Modify"? Does your problem go away if you turn off all snaps? Does the problem decrease if you set layer options to "Active Only"? Have you taken any 3D sections of your model? In my experience these things can affect performance to the degree you report. Multiple layer links also seem to slow things down. I am not aware of any problem related to creation classes for PIOs, but I wouldn't necessarily rule it out. For those who are frustrated with VW: in an AutoCAD drawing with multiple xref's and layouts (the equivalent to multiple layer links / workgroup refs in VW), it can literally take 30 seconds to switch layouts on a fast computer. [ 11-14-2004, 02:38 PM: Message edited by: P Retondo ]

I notice a dramatic decrease in performance when a layer has multiple layer links. Don't know if this would occur with the new viewports. VW 10.5.1 Win2k/XP [ 11-13-2004, 04:23 PM: Message edited by: P Retondo ]

I recently experienced a file corruption that caused me a great deal of time and trouble. A class I created somehow became the default class, and many of my PIO objects and all new groups (v10.5.1) were automatically assigned to this "renegade" class. Among the many other little difficulties this creates: the Wall Type dialog box no longer listed "None" as a class assignment option, but instead listed my renegade class. Technical support says they can't track this bug down, and I don't fault them. But, to prevent this happening, VW should be modified so that it is impossible for the default class to be renamed or otherwise substituted, either deliberately or through internal error.