Jeffrey W Ouellette

I would second this one also. I think it ties into the issue of wall cavities as model vs. graphic entities. When modeling, the finish surfaces are most important, but in construction documents, it's all about the type of drawing you need. For example, on floor plans, you want to be able to dimension to the face of framing, face of masonry or face of structural concrete, even if you can see the "finish" cavities. Most cases though, at 1/4" scale or less, only the structural cavity (or additional masonry cavity) is shown, not the plywood or gypsum sheathing, stucco, siding, etc. Otherwise the drawing can become too congested with lines. This can be sloppy and confusing. At larger, detail scales (1" or more), which may indicate specific section or plan conditions, it is important to show all components of the wall (unless they are just structural drawings). This means including exterior and interior finishes and a graphic means of differentiating between materials (i.e. hatching/poche). The true modeling CADD programs I have personally used (VW & ArchiCAD) both struggle wth how this optimally works. The difficulty seems to be in changing the nature of the walls display based upon view (plan, section, elevation) and the control elements/edges vs. model/graphic components. I'm sure it is no simple programming issue. It seems that the demand is for a hierarchy of elements that is counter intuitive to the "wall" command structure which focuses on the totality of the wall being one way or another, not four dfferent ways at once. One path of resolution may be the use of CLASSES to each wall component. That way the visibility of the components/cavities may be controlled by visibility setups for desired views. This, of course adds another level of complexity to wall objects... and another level of nomenclature that I'm already buried in and was hoping to escape from in ArchiCAD. Sometimes there is such a thing as too much control... no?

Thanks ol' teammate. Found "SKU". Now Schedule works like a charm. But could I make a few formal suggestions on additional default record fields and naming conventions?.... Must wait 'til after this project is done.

OK, I've deciphered that the "Manufacturers" field is actually called "Manuf". But I still haven't found the proper reference for "Stock No.". Are these field for PIO listed ant where for reference? I can't seem to find anything in the manual.

In a related subject to the previous post, I want to add fields/columns to the Door Schedule to include the "Manufacturer" and "Stock No." fields, but am unable to extract this data when these database headers are added to the worksheet. Am I missing the proper(correct) name for these fields? or have I missed something on the format/nomenclature?

I would humbly concur...

Thanks, Robert!!

G McBeath, Thanks for the working solution. I only wish I could see it in a [3'-0"] format instead of [3'0"]. Picky, but it is a matter of convention/tradition one gets used to. LMT, I agree that the PIOs and Scheduling functions are far from perfect. I only have ArchiCAD 9 to compare to and found the ArchiCAD has it down pretty well, but VWA is not far off. Just a little tweaking is needed. I may have to return to the previous method of a separate ID symbol with the record fields and formats I prefer to show. I was hoping to showcase more of VWA12 functions with this project. However, I don't want the showcase to obscure the Construction Document Set's function.

1) I use the new door and window PIOs and I select the "On Schedule" option. 2) I use the "Tools/Reports/VA Create Schedule..." Menu command. 3) I select the appropriate door or window schedule options from the list. 4) When the quite extensive and large schedule appears, all dimension fields are in a neutral number format, apparently representing decimal inches. 5) When I try to alter the format of these fields, I try to choose the "Number/Dimensional" format. 6) I get a very strange result. Instead of converting [32] to [2'-8"] it changes to [32'0"]. That's not what I expected, wanted, nor find acceptable. 7) I cannot seem to locate an option to get the output I desire, so much merely add ["} to the "Trailer" field. 8) Am I missing something, or are you going tell me something where I regret using the PIO's labeling functions?

Q4U, I would second Matthew's evaluation. I've used AutoCAD (in more than a couple of its various flavors), VW/MiniCAD, ArchiCAD 8&9 & CADVANCE. I've dabbled with SketchUp, MicroStation & DataCAD. ArchiCAD is the gold standard. It is a supreme 3D design/modeling tool. But, after working with VW for so long, I found it a bit awkward in developing 2D CDs. It does some things very cleverly and others very quirkily. So does VW for that matter. VW is working toward being the gold standard. It has been getting significantly closer with each new version/development cycle. While ArchiCAD has been spending much of its time lately tweaking what it does, VWA has been taking HUGE steps in its functionality to match ArchiCAD, while squashing bugs. In the US, there is a big price difference between the two packages, a difference in VW's favor. After spending 1 1/2 years on ArchiCAD, I will admit I was very reluctant to move back to VW. There are things I do still miss about ArchiCAD. But after diving into VW 11 & 12, I've got the VW bug again, looking forward to each new versin and putting my two cents in with forums like this, hoping I can give some worthy feedback to the developers in Columbia.

OK, I have to gripe about this. It's driving me nutty. After being away from VW for about 1 1/2 years and coming back to work with v11.5, I was pleasantly suprised by a lot of changes. But, of course, with each new major version, there are some glitches. I hadn't had anything in 11.5 irk me, but the upgrade from 11.5 to 12 really has me steaming... all over little itty bitty issues, parts of a larger program update and strategy. At this moment my despair is... The conversion of door/window PIOs. When opening a file created in v11.5, v12 takes a while to cycle through the drawing and update PIOs to the new ones. For me, this has been with distressing results. As the new converted drawing comes up, the doors are gone. Apparently the new PIO uses a new class to demark/display newly delimited parts of the object. This class is NOT a part of my original Class visibility structure. While this may seem trite, it is annoying because when I turn the new class on, the lineweight and color (and thus visibilty and printing output) of the door PIOs is now incorrect/inconsistent with my drawing standard. It means a lot of new work on my end to fix these things. It also means another shift for the whole office to deal with. Don't get me wrong, I have appreciated all of the advances NNA has made with VW toward matching the BIM power of a program like ArchiCAD, but sometimes these improvements in programming and features set me back in terms of practical productivity while I adapt/adjust/relearn. Please, please, please be more conscious of this while continuing to advance VW. Moving forward with the programming at every version should not push those of us applying the program to everyday practice backward at the same time, with every step.

I guess with all the new code for all the new functionality and features, some processes tend to be a bit redundant, especially in the Class/Layer visibilty arena. While I appreciate additional control options and ability to tailor drawing appearance, I feel that this may have taken a step in the wrong direction, or at least an even less intuitive one. Please refer to my post in the General Discussion board "Viewport Annotation Mode not working properly" http://techboard.nemetschek.net/cgi/ubb/ultimatebb.cgi?ubb=send_topic;t=005696;f=12 The current manual documentation doesn't seem to address these distinctions very well.

OK, I think I've isolated the problem/situation. I guess it is a misunderstanding on my part, but I feel it is very counter intuitive. 1) The Viewport has all the appropriate Classes visible. 2) The Sheet Layer, however, has only the Classes visible that I felt were relevent to the display of the Sheet (i.e. "none" and "A-NOTE") 3) At this point, all items of and in the desired Viewport are snappable(?). But when Edit->Annotation is invoked, only items newly drawn in the Annotation Mode are "snappable". 4) When I exit the Edit/Annotation Mode and make all the Viewport classes visible, the result is the same. 5) However, if I make all Classes visible in the current view of the current Sheet Layer, then I am able to snap to all the objects displayed in the Viewport while in Edit->Annotation Mode. Furthermore, this does not effect the ability to snap to all items of and in the Viewport while on the Sheet Layer. I feel this is a bit counterintuitive. It just feels like there is a disconnect between the View setups and the way the program ultimately handles info. I guess I would have expected the other classes within the viewport not to be visible if the same classes of the Sheet Layer view were also not visible. Either a can of worms or another quirky conundrum for us users to work around.

Yes. I can snap to the boudaries of the viewport and all of the objects within the viewport, but not to the contents of the Viewport when in Edit->Annotation Mode. I know it's funky... I'm stumped and frustrated. I guess I'll go back to dimensioning and noting in the design layers, but was really trying to take advantage of various viewports displaying different information (classes) of the same layer (floor) for different views (floor plan, reflected ceiling plan, site plan...). NNA? Any suggestions?

I am trying to dimension walls, windows, doors, slabs, etc. Strangely enough, I can snap (so say the SmartCursor Cues) to the plan view objects in the Viewport without entering the Edit mode. In other words, when I am on the appropriate Sheet Layer, with the desired Viewport, all desired classes visible, I can snap to anything in th viewport. But when I enter the Annotation Mode of the Viewport I cannot snap to anything except what I've newly drawn in the Annotation mode.

In attempting to finish my first set of VWA12 Construction Documents, I am trying to layout dimensions and section/elevation indicators in the "Annotation" mode of the Edit Viewport Command. However, I am not getting anything to snap to the referenced drawing/view. I have all the appropriate classes on... I even turned them ALL on (in all places) to be sure. No go. Bug? Or am I still missing something? I've poured over all the other similar posts, but they seem to lack resolution to this situation also. Prompt assistance is needed. Thanks.

Is it possible to add an option to the window PIO to move the trim on both the interior or exterior to the outside of the frame, rather than overlapping the frame? For example, when using a residential aluminum clad window like Kolbe&Kolbe, I often need to trim around the exterior frame which already protrudes 1 1/4" beyond the face of the wall because it is installed with a nailing flange. We don't overlap the face of the frame, but surround it, covering the typical nailing flange. This is very, very, very common with many modern windows that are of the aluminum/vinyl clad wood variety or wholly aluminum framed. With wood windows, you can specify a factory applied brick mold or add trim onsite that does cover the face of the frame. The current PIO works pretty well for this situation. More and more of our specified window systems, however, are of the clad or aluminum frame varieties that have nailing flanges and protrude from the face of the sheathed wall.

Ok, I'll admit, I'm stumbling and fumbling a bit with the new VWA. I can't for the life of me figure out why my doors (all parametric objects at this point in the design/drawings) only show jambs when opened in VWA12. The appear correctly in VWA11. I know the PIO is supposed to be different, but WHOA, NELLY!!!! THAT'S SHOCKINGLY DIFFERENT! It's seems as overwhelming in detail as ArchiCAD.

Thanks Peter! That worked.... but it shouldn't have. Why do the door leaves default to "SILLS". Why would they switch visibilty from VWA11 to VWA12? In creating the new PIO, shouldn't defaults be totally neutral (i.e. "None" class)? In my case, I had mapped the default VWA Class "SILLS" to "A-WIN-SILL". This made the sleuthing a bit more complex. How many other PIOs can I expect this on?

There is not a ".skp" option currently available in VW12 Windoze

I have used the HP500 w/ VW and Mac OS X. There are native Mac OS X drivers for it from HP, as well as native support from 10.4. I'm unsure about the OS 9 side. Dont' waste the money on the PS version. It will provide excellent output, both B&W and color, without it. Jusy make sure to get the internal print server card and as much RAM as you can afford.

For two years I was using a HP500 (color) 42". The first year I was forced to use ESP Print Pro for MacOS X drivers. But last year HP finally came out with a OS X driver. Now, it is supported natively by 10.4 (Tiger). I think the B&W output with the HP/Apple drivers was very good and the color output was also very good with some extensive tweaking of various driver and application settings. Don't get the 'PS' model. It is a waste of money with the native drivers available now. But you will need an HP internal print server if you print via ethernet. Get as much RAM as you can afford (HP's memory is very pricey).

So, with all this excitement and 12 yet to be in hand, do I dare ask when 12.1 will be available? This is assuming 12.1 will be a bug fix release only 11.5.1, not a feature and bug fix release like 11.5.

Would someone from Nemetschek Tech Suport like to weigh in on this very legitimate, persistent and annoying issue? I've had to live with this problem also, most recently in printing to a HP488ca from a Mac mini w/ OSX 10.4.2. It really messes up some otherwise nice drawings and is noticed by my contractors and clients as well. Is it really that hard to fix or such a low priority?

I fully understand the PIO-to-hybrid-symbol process. However, in the case of Schematic Design of custom modern residences, many times we are moving quickly to place openings of various sizes in many locations (excellent application of the PIO) without establishing any regular system that the symbol process works better at. These opening must remain flexible in their parametrtic features from each other for our needs in the SD and DD process. I feel the issue I'm running into is more a program/processing dilemna than a end user habit.

Try novaPDF Professional @ www.novapdf.com. Works well as a basic PDF creator for much less than Acrobat.