Ken

Probably the lighter trim lines affectively masking some wall edges and not others, in Hidden Line render? (If so, this is a pet peeve of mine, which I'll post again as a wish item now that you have me revisiting it)

Please attach or link a pic or VWX file for graphical reference. It would help. Basically you can go to a side view, double-click on the wall, then stretch one of its handles to go up or down making the wall sloped.

Are you talking about plan view? Or orthogonal elevation view?

Bob, it's the built-in Fractional Display for Dimensions that's not affecting your override in the OIP. This is one case where I cannot complain too much, although I agree with how inconsistent a combo dim string can be. Before this fractional display was a feature, I was using a font called Helvetica Fractions. It was a separate purchase at some odd $29. It allowed fractional displays with any numerator and denominator in two styles ? horizontal or angle separator. It was system wide usage, so you could do it in MS Word, etc. I even switched globally to Helvetica font for all my drawings. However, it was not always easy to use. Ugggh. And it could NOT be entered in VW as dimensional override. It didn't effect dimensions at all, so I had to manually place opaque text blocks on dimension lines when showing fractions was critical. Now we have dimensional fractions Vectorworks. No more need for Helvetica Fractions! Woohoo! The font doesn't load in OS 10.6 anyway. Good riddance. Now the workaround is reversed: Duplicate your dimension in place (option click) The dim you want to show fractions: Delete its constraints if necessary (the duplicate should be clear) Double-click on it to change its value Set its line thickness to 0.00 for invisibility Send to Front (if not already there) to mask the other dim [*] The other dim shows just the lines, so uncheck its Show Dim Value It's not technically kosher, but it's pretty.

Yes, Mike. I think it's particularly messy/ annoying/ glitchy when there are preexisting Saved Views, which might be the usual case if people are not so versed in having to replace all Saved Views with new Saved Views of the same thing but with just the Restore Unified View option checked EACH AND EVERY time that unified view is saved anywhere in the drawing! Thanks for exploring this with me.

So now I'm trying to take advantage of this "new" behavior. When I duplicate a joined wall (copy and paste, duplicate, option-click, whatever) for use elsewhere THEN USE MOVE 3D SELECTION on it, the joined ends stay mitered! They don't automatically heal as I would expect if this new behavior is true. If you people are not claiming this as a bug, what exactly are you advocating? :mad:

Matt, the download link is broken. My browser seems to retrieve a file called, "panzercad.com" I'm very curious how you did it.

Geez, Mike, and you seem to be talking from experience.

But I have, Mike. For example, my layers, super simplified, are: -Walls -Notes -Roof (3D) -Model (linked layer) My "floor plan" saved view is just Walls and Notes. My unified layer model view is just having the Walls and Roof (3D) layer visible. I created a saved view for it with Restore Unified View checked. My Unified View Options include everything checkmarked. So when I go into the saved view to look at my unified layer model, it's first in planview because I had been working on the floor plan in top/plan view. When I look at my model in perspective (RW camera), then go back to my floor plan saved view, the Unified View is still on! The walls are all still in perspective! Shouldn't Unified View turn off automatically when I go to another saved view? That's why I go to my blank layer called Model and pull in the same layers as links.

In Hidden Line render mode, it seems switching the various standard views (top, front, right, back, right isometric, left iso, etc.) involves a tremendous lag -- much more than in earlier versions. And all while Final Quality Renderworks is blazing along *faster* than before probably due to my faster video processor. Anybody else?

Another huge advantage occurs when coming out of a unified layer view. For layer links I don't have to darn *remember* to be looking in top/plan (supposed to be whole building model view) before leaving it to work on my floor plan. In unified layers I can't return to the same perspective because I have enter and leave in top/plan. And I'm not talking about Renderworks Camera either. This is just going back and forth to variously work on the model. Then there's a top/plan viewport that's also affected. What am I missing?

Upon further testing, it's actually isolated to just that file. The complete drawing file is actually my current project (deadline soon, yikes!), but the problem does not seem to appear anywhere else (in other files), so I'm not going to chase any wild geese talking with tech support. Surely we have the genius among us collectively to figure it out, no? :grin:

I agree. For me, I only use this one, as part of a larger script: SetConstrain('qwd');

OK, I've isolated the problem to one file. I've reduced the file to three objects. Attached is the file. I still cannot figure out what's the problem.

How about using two single-line scripts -- one to turn 'em all on, another to turn 'em all off. SetConstrain('qwerasdf'); SetConstrain('');

Of course I have no choice but to adapt to using the OIP instead of Move 3D Selection or dragging. But there's absolutely an inconsistency in this behavior, IMO. I can see how the Move 2D command should "heal" a wall join, but any Z-direction movement should definitely not affect the wall join regardless of the tool, command or method. There are also clever instances when I actually do want to keep the mitered edge of a joined wall to cover corners elsewhere. I can still use a duplicated joined wall to achieve this without it suddenly unjoining on me, even in plan view same Z value. This surely is inconsistent behavior regardless of the new parasolid technology.

Specifically, a roof face object in side orthogonal view. Totally possible in previous versions of VW. Now it's entirely missing.

It's truly the best of all worlds once you decide to let the large ball do all the work in movements. No need to move your arm. It's the most compact and intuitive motion ever. You simply spin/ rotate/ roll the ball. Sometimes I find myself using two fingers -- index and middle finger. But usually just index finger. When the ball rolls up, the cursor goes up on the screen. You can make precise patterns with the ball just after a few minutes of practice. The ball can be lifted out for cleaning. It's just like a billiards ball. It doesn't pop out however fast you work because of the clever pocket dimensions. It's an entire genre better than any of the tiny ball devices. My TurboMouse model rides freely on three stainless steel rollers -- three points of contact. The newer Slimblade also sits on three points, but they're low friction Teflon-type contacts, with optical tracking of the ball surface so the new ball has to be that red color. I wished the newer model also had free spinning roller contact points. By default either of the lower buttons is a single click, similar to any mouse click. You quickly adapt to the intuitive action of dragging by holding the button with your thumb and spinning/ rotating/ rolling the ball with your index and/or middle finger(s). The genius is really in the size and positioning of all four buttons. I use the diagonal opposite button for double click directly under my middle finger, so the common Vectorworks click-double-click actions are downright natural and a breeze. I have the other lower button as control-click (or right click in Windows) for the VW contextual menu, the fourth button for general applications switching. When you hold the spacebar for tool-in-use panning (same for any mouse device and activated by your other hand), you can temporarily release the click-hold in dragging your object and Vectorworks lets you finish the action in click-click mode (as opposed to click-drag mode) regardless of your preference settings. Zooming can and should also be done with your other hand (keyboard shortcuts) with any object dragging in use, regardless of your pointing device, IMHO. There's a free download driver that lets you adjust the acceleration and set your preferences (programming it). I have it installed for both my Mac and Win95 XP. When the driver is not installed, it works just like a regular mouse with all the buttons being a single click. I can't say enough about it. Absolutely recommended.

I lament the discontinuation of the Kensington 4-button TurboMouse (roller ball bearing version), which I consider the best ever and which I'm fortunate enough to still use, praying for mine to never break down, which actually seems a reasonable wish given its simple design and durability: There's an upcoming version, bypassing all those ill-conceived changes to the above model, but which is still unfulfilled for programmability due to lack of software, called Slimblade by Kensington, yet may feel "cheap" compared to the heavy ball-bearing older model: Thumb button is single click, diagonal opposite button is double click. You cannot rest your hand in a more natural relaxed position yet still allow total cursor movement in any direction at any pace. I do it for many hours everyday without a hint of strain.

The shortest cut is to put a VS somewhere in your workspace, then assign a keystroke to it. I believe it's as simple as inserting the SetConstrain one-liner.

Mike, this is hauntingly reminiscent of my battles with authority when really nifty features got wiped out for sake of "improvement." The way you describe it now as "common behavior" is sad because the very procedure worked just fine in v2009 and in the version that I've used for eons -- v2008. In fact, I must have happily used the Move 3D Selection on walls about TEN THOUSAND TIMES in over TWO HUNDRED projects without any wall joins suddenly unjoining afterwards. And now you make it seem like the world revolves the opposite direction, that I have to specifically ask for it on the wish list! How can it NOT be a bug? What can possibly be wrong with keeping the old tried and true behavior?

So the bug resides in the Move 3D Selection command? And also in grabbing/dragging/snapping the wall in side orthogonal view?

Yes. Submitted. I do remember submitting this as a bug when v2008 first came out. Same behavior in v2009. Now same behavior in v2010. You guessed right. If this situation is exported all the way back to v12, the tool works fine! :mad:

Ahhaa! Thank you, Mike. So now I return to *testing* Unified View...

This works at least in v2008 (I'm still pulling my hair out using v2010): 1. On the same layer as your sloping roof face, create a temporary horizontal roof face (zero pitch) the bottom of which has same global Z position as the top of your subject wall. 2. Temporarily *cut* (Command-X) any other roof faces that may sit below this temporary roof and the your sloping roof face. If there are none, skip this step. 3. Use Fit Walls To Roof command, selecting the proper layer where your roof faces reside. 4. Done. Go back to delete temporary roof face created in step 1. 5. Paste back in place (Option-Command-V) the roof faces from step #2 on the proper layer (if the step was required).