brudgers

Sounds more like a graphics subsystem type problem than directly related to entities. Does it persist through a reboot, or does it take awhile for it to happen?

I think he means the frame, not the leaf. Such frames are common for commercial 7'-0" doors in masonry walls. So far as I am aware, the standard door plugin cannot have a variable width frame...at least that's the case in VW2008. It can be faked for rendering by: set jamb width = 0 interior trim = 2 exterior trim = 2 lintel thickness = 2 lintel angle = 90 exterior trim thickness = interior trim thickness = lintel protrusion assign same material to lintel and trims. For 2d you will get a line betwen the trim and lintel.

It's not quite that bad. Objects retain their "thickness" (aka line weight) regardless of the user preferences stored in the XML file. The preference setting just determines which lineweights are available for default selection. Otherwise the user has to select "set thickness" from the listbox and assign the weight manually. All line weights are always available, but only certain ones are convenient.

Even if it is, why require everyone to use the same preferences?

As I said earlier: The only reason NNA had to create another (user inaccessible) interface for things like the stack layer command, is because the tool pallet interface is so limited. Maybe if they weren't so busy chasing their tail patching code for ISO 95014 compatiblity, they could do the needed rewrite. 20 years ago, compiling the UI might have made sense for speed. It doesn't today.

I can rearrange "tool" pallets on the fly for better access...without editing the workspace. You can't do that with drop down menus or keyboard shortcuts. Pallets allow the user to expose or hide functionality "at runtime" rather than requiring "recompilation." (That's a metaphor, just want to spell it out for you).

How refreshing, I haven't seen someone push PARC down the memory hole all week. The tool/command distinction may be useful for a programmer...but reflecting it in the user interface is hardly modern practice. Creating a rigid user interface base on what is convenient for trainers and programmers, well that's just bad design + an excuse. And the fact that you have to explain the tool/command distinction is evidence thereof. BTW, it's good to know that the stack layers button "serves no useful purpose whatsoever," despite its obvious utility. You should add that to your signature.

If you want an icon to activate it, just live with the extra click. I often find it less cumbersome than: 1. Burying it in a pull down menu 2. or assigning it an obscure keyboard combination that I'll never remember because I only use the tool five days a year and which requires me to take my hand off the mouse and/or look at the keyboard. 3. Modifying every drawing and template to add it as a script. Even if some people find the extra click to be sacreligous...

I would guess that the plug-in is based on Euler?Bernoulli beam theory. You could call NNA to verify this. But perhaps they taught some other theory at Bath?

They hadn't updated it for 2009. Maybe the have.

Whatever logic is behind distinguishing between tools and commands does not encompass the fact that you cannot run a command from an icon (particularly since you can both run tools and commands from the other user interfaces (drop down menus and the keyboard). Heck you can even click on the name of a script and it will run a command despite being in a pallet. The behaviour is inexcusable. BTW, "learn C++" is the answer to every vectorworks limitation, 'cause then you can just write your own CAD program.

Alexandria Laundry Lofts is in VW2008 format.

It doesn't really perform strutural analysis. It merely will calculate one property of the section given the others. It's not a substitute for an engineer.

The way you defend the tool/command distinction it must come from 95014. BTW, congratulations. I doubt I could have spelled it out any further.

L-2 = Toxic waste. L-1 = Lawyers. L = ?

Then the script will not work the way the person wants it to work. Hardly "Best." More like, "Your script will be limited in a different way by the failures of the user interface." The theoretical tool/command distinction should be independent of the interface used to access...the restriction of the icon interface to tools is inexcusable. BTW, I've recently realized that part of the UI limitation is the fact that you cannot modify the contents of the workspace transparently. Just rearrange the deck chairs.

Yes they're two separate methods...in many ways...one being that DB is an actual common practice and IPD is a largely theoretical construct. Here, while IPD generally requires shared data models and DB does not necessarily, the most vast preponderance of data sharing between architect and builder occurs within the context of design build. Here, from the builder's standpoint (aka: where all the money is) Design Build provides detailed design information much earlier in the process than traditional design-bid-build. The real down side to Design Build is the same as with any development activity, the cost of the due diligence to determine feasibility and viability.

I guess the whooshing sound didn't wake you up.

I wouldn't recommend copying the file from computer to computer. Just edit each copy over the network using a script.

The line thickness is stored in Field is Values are width in mils.

Llareggub was last.

Snow Leopard doesn't support VW 2008.

I always know when you've finally recognized how wrong you are.

Draw a bell curve.

Doesn't matter if the software knows about the door. Mira los planos!