mr. iagea

Thanks for the suggestion, Pat. I did not add nor edit a Drawing Number data field to my title block. I'll experiment with that and let you know how it shapes up.

I can edit the text info manually if I place the drawing label on the design layer (where it'll show up in the VP), but then everything about it becomes a manual process. If I happen to change the order of several VP's placed on a sheet, I thn have to go back to each layer and manually fix the drawing labels to reflect their correct order position. That kinda defeats the nice automation of the whole thing in the first place, yes? If I place the label inside the VP annotation, that's also where the label's sheet number is not reflecting the proper sheet. So, I guess I'd like to figure out why this is happening because at this point, it's creating a little extra work and limiting the usability of my design layers (if I have to put a particular sheet's drawing label directly on the DL, then I cannot use that for a VP on a different sheet).

Anyone? Please?

I'm having some drawing label trouble. Each time I place a drawing label either on a viewport or sheet layer, the sheet number NEVER shows me the proper ID. It always shows up as "A0", no matter which sheet I place a label on. Of course, this happens only when I have the bubble split to show item and sheet number. Now, before you tell me to edit the sheet number in the OIP...that's not possible. The field is greyed out and uneditable. This is true no matter where I place the label. Now, I can certainly have a fully editable label if I place it on a design layer, but then the item number and sheet numbers no longer set automatically, so I lose the whole functionality of having the label's data auto-populated anyway. I've set up many sheet layers and updated the title blocks on each to reflect the proper sheet number. Everything there seems to be working correctly. I know this is supposed to work, but it's not. I've seen other posts about this, as well. Anyone have any ideas?

I don't seem to be able to edit the name of an existing viewport. Can this be done at all? I have one that I've mistyped the name and I'd rather not delete it and rebuild it, as it has quite a bit of dimensional info drawn in the annotation. Thanks!

Cool. Good to know the Sketch default issue was fixed. In regard to my second problem, the trouble seems to be when I go from Wireframe to Polygon Final Shaded. I never use Sketch, so it's not checked in the View > Rendering menu. What IS checked in that menu is Polygon Final Shaded. However, once I switch to PFS from the Render Mode dropdown menu in the main drawing window, the drawing renders using the default document sketch mode (which always slips back to "Rough"), instead of crisply lined and shaded polygons. This seems to be coincidental with the sketch mode default issue of this current thread. I took a look in the "Options for Other Render Modes" in that Render Modes dropdown menu and unchecked all the boxes having anything to do with Sketch. I'm hoping this remedies the trouble. Lastly, I'm also interested in knowing if the Sketch Preview problem was fixed in 2009. In my version of 2008, when I select any of the Sketch Modes (from View > Rendering > Sketch Options... (then select any Sketch Mode, then the subsequent "Edit" button which becomes available), a window is presented that allows the user to alter the discrete attributes of the chosen sketch style (such as "Wobble", "Stroke" and "Randomness"). There is an image of a house gable end, which is ostensibly meant to dynamically preview the attribute changes in real time. This does not happen on my machine at all. It's minor, but it was one of the first things I discovered as broken when I initially purchased the software. Extensive discussions with NNA, as well as a hardware upgrade, did not solve the problem and I cannot recall if I submitted it as a bug. I think I may have. I know it's a minor thing compared to some other workflow-halting issues, but I'm curious if this was addressed in 2009.

I have an update to this problem, which I am experiencing as well with a great deal of frustration. I have noticed that my sketch style not only defaults to Rough when opening the file, but also after a period of time after the file is opened, even if I have changed it back to "No Sketch". Tracking this, I noticed that it seems to happen soon after a Autosave backup is made. I've noticed that this sketch anomaly seems to happen when I select the Final Polygon Shaded render mode. That comes up as rough sketch, rather than a crisp shaded drawing. Frustrating. Also, I noticed that my Sketch Preview (the little window with the house, roof and gable) simply does not draw the updates on the screen when I adjust the various sliders, making that completely useless. I spoke at great length about this with NNA, only to discover that they had no idea what the problem was. I do hope these things were fixed in 2009. Can someone who has 2009 please try it and let the forum know? Thanks!

Thanks, Jeffrey. I agree that tutoring would be helpful. Pat's comments here on the boards have helped me a lot already.

Fair enough, Petri. I'm not suggesting that flexibility should be discarded or that a CAD database use foundation is flawed. I'm merely responding to "first-use" experience with the door schedule. I feel first use is essential to a users' overall understanding of an application. Yes, I did feel that dragging the icon to sort was an unintuitive first-use experience, as I clearly pointed out in my previous post. Now that I understand that that is how it works, I can use that info later. My troubles to date are because these important pieces of info don't seem to be presented in relevant locations in the manuals or help system (or at all). So, here we are. One must ask other users. Granted, I am pretty frustrated by the time I post for help, as I do employ my intelligence and experience in ferreting out solutions prior to posting. In those cases on my own, to no avail. Perhaps it would serve me well to calm down a bit before composing?I readily admit that my tone could be perceived as angry, which I am not. I'm simply trying to get my work done and learn his application, which I'm fairly new to, if you haven't already picked that up . I find the learning curve...an experience, shall we say? Problem solved. Back to work with me now?I've spent enough time on this matter. Thanks all for the help. It's greatly appreciated.

Ah, that was it. I was dimensioning between two walls (as across a hallway, for example, for clarity for my client), rather than two vertices. Now I understand. Thanks very much, dcont.

In my example, a contextual menu function would be object specific, as it is in almost every other drawing software (and OS, for that matter) on the market. So, it wouldn't matter which database or worksheet item one was viewing. One would simply select with a right-click the column by which the present worksheet should be sorted. That then brings up the contextual menu with a sort function in that menu. It's basically the same thing as what's happening now with the teeny chiclet things, except that the function is moved to a contextual menu, with language prompts instead of iconic prompts. But additionally, after the sort function is performed the icon could then be placed in the column's header by the application as an indicator (as it is now, but not until the user moves it to that location). This does several things: First, it is a known user interface method. Contextual menus are de riguer now, so it is a very intuitive action to take when a user is presented with an unknown. Second, by placing the icon of the chiclet in the column after a successful right-click sort, the software is essentially teaching the user by example what the chiclet icon is meant to do (or at least indicate). Later experimentation could result in the user learning that moving the icon ALSO sorts, but a familiar UI method should work first (and/or there is a main menu item for the function). This is essential in proper UI design. Lastly, by allowing the user to employ a known action to an unknown element, and then reinforcing that action with success, the user gains confidence both in the software and also in his/her ability to produce desired results with the software. Of course, this elegance must be prevalent elsewhere in the functionality of the software's other tools and functions, which is why it is critical that UI is considered FIRST in developing ANY software (IMHO). After all, it is the user who will drive the application down the road, not the other way around. Going back to the chiclets for a moment: at first glance, it's very difficult to tell that the chiclet is representing a bar chart. And then, assuming that one can tell that it's a bar chart, how does a bar chart relate to sorting? Maybe to one group of the user base it does. But to the remaining group it might not, and so those people's brains may subconsciously dismiss the object. So, our sorting chiclet is greyed out until one clicks on a ROW (which is not usually how one wishes to sort). Then the chiclet becomes dark, which suggests to a first time user that the chiclet is a BUTTON that should be clicked to employ an underlying function. That is exactly what I did the first time I came across this. But, clicking on it does nothing, so again it is dismissed as a functional object and from then on thought to be an indicator (of what is not initially obvious). It is unintuitive to expect the initial use of the chiclet icon as not a button, but rather a movable object that should now be placed in a column header to sort by that column. Especially when the process suggests that it IS a button (select row, icon becomes "available" by indication of it becoming dark). The trouble with iconic function prompts in software is that it is implicit that the user understands the icon prior to its first use. This is very difficult to convey with icons that are intended to express some kind of known object, like a bar chart, as in the case of this chiclet in the worksheet. The design of the icon is a completely subjective process, left to the skill of whomever the developer chooses to design the UI. A bad choice there can cripple the efficacy of a function or the entire application. Unintuitive UI is damaging to software more than that the functions aren't easily learned and employed. It also leaves users with an uneasy subconscious feeling about the software?that perhaps the software is not able to do what the users needs. Or, for others with lower self-confidence levels or unique learning styles (there are seven documented learning styles, all equally valid), they feel that THEY are the problem, that there is something wrong with their abilities, or that they are daft. Regardless of the state of mind of a user, an application should always serve to assist a user in achieving the desired work, and it should do it in as invisible a manner as possible. One need only look at the UI of the Mac OS, for example. Sorting items in a window is done with a very intuitive triangle in the bar of column headers. Clicking the triangle sorts by that column. Up or down triangle indicates the current sort presentation. This is elegance at its best. The icon is both indicator and button, and a symbol that is universally understood. I get that the Worksheets in VW may be "more complex", with several databases, but I ask: should they be? Simple database management is computing at its most basic, and yes, these databases are simple by comparison. Should a simple sorting function be made more complicated than what already exists in software and OS's already in existence? I think not. If the developer wishes to sell more units, make the software easy to use for more people. Simple metrics, in my book. 'Nuff said from me on the topic.

Yes, Associative Dimensioning is turned on, as is Auto-Associate, and the Dimension Class checkbox.

Okay, I get the sorting function. That worked. That method, by the way, is the most unintuitive unclear way of sorting a database I've ever seen in a software application. Wouldn't a contextual menu item "Sort by...", when the desired column to sort by is selected, be more clear? I think so. I finally found the "Edit Criteria" for the actual door list. I had to select "Database Headers" first before getting that option. I had to then set my criteria to show only the layers I wanted, as explained by Pat (thanks again, Pat. You've been a great help to me this week!). Okay, so that finally worked. But not until after way too much wasted time trying to get this sorted out. This should be a default setting. And the manual should be absolutely clear about the process to get this done. And neither of those things are the case here, and in many other things I've tried to get done recently. And this really brings me to the core of my difficulty with this software: The defaults are all wrong, as if the developers don't actually use it to make architectural drawings (or even CAD drawings, for matter, but if this is touted as an Architect solution, it should function as one). This feels like it was made by a software engineer committee that forgot to consult a UI expert. Secondly, I find that most of the manuals are inadequate in explaining these little nuances (otherwise, why I am spending more time this week on this forum, trying to find the answers to what should be obvious solutions?). I consider myself an intelligent man, and as a university instuctor for drawing software and design for nearly 10 years now, I am confident that I know something about software, user interaction and the learning process. IMFO (F="frustrated"), this software is quite difficult to learn, because it is not explained adequately and not presented very well. Yes, it is showing itself finally to be powerful, even elegant at times, but the learning curve could be made MUCH EASIER (and the sales figures would rise as well, I expect) if NNA would take the time to present the software more clearly in the manuals. There are two volumes at nearly 1000 pages total. Cannot all those pages be used to better explain HOW to get stuff done, such as this ostensibly basic Door Schedule stuff, for example? My 2 cents, FWIW, at the end of a frustrating and long day on deadline. Pardon my rant on UI. Thanks for the suggestions and assistance. Much appreciated!

So, I'm beginning to wonder if anything works correctly the first time I do it. This time, I followed the manual's instructions to the letter, and the operation STILL didn't work. So, On a Sheet layer viewport, I am able to add dimensioning using "any of the dimensioning tools", according to the manual and the online Help, and those dimensions should change if the design layer changes. Well, they didn't change. I dimensioned a wall in the Edit Annotation section of the Sheet Layer viewport, using a simple unconstrained dimension (tried it with constrained dimensioning too, just to be sure). Then, I went back to the design layer, moved the wall, then went back to the Viewport, selected "Update All Viewports", and the dimensions did NOT change with the wall edit. Is there something I'm missing here?

cool. thanks, Pat.

...so I only use a viewport once? The same viewport is not usable in multiple locations (on different sheet layers or design layers)? Thanks for the quick info. I wish the manuals were that simple.

I'm not sure I understand, then. Without seeing the problem, it's hard to say, if these suggestions aren't fixing it. Does the window appear to render properly in 3D view?

Okay, so I'm really feeling like an idiot today. Maybe I don't understand the purpose of a sheet layer. I'm under the impression that I can make a sheet layer to hold a viewport of the drawing that's on the design layer so that I can print out my sheets, but also so that I can add separate dimensions, notes, etc. than what's on the design layer(s). (yes, no, way off?) All I'm trying to do is temporarily show dimensioning of the room sizes for my client (they want to figure out where their existing furniture will fit in). I don't want these dimensions on the final set of plans, because I'll be putting in standard dimensions that the builder understands. So, I made a viewport of my first floor plan, using my drawing on a design layer, and then placed this on a sheet layer, thinking this was the right way to print off a sheet for the client to review. I understood the manual and help files to say that I could then add annotations and dimensions, etc. on that sheet layer. But, the dimensions aren't correct?they're indicating the PAGE dimensions, rather than the room dimensions, as it works on the design layer. So, at a scale of 1:48, I get a two foot room showing up as 5/8". What's happening here? This seems like a pretty basic operation. Again, maybe I'm misunderstanding how sheet layers work (or supposed to). I tried to add the dimensions on a viewport, but that's showing page dimensions, also. Thanks.

Okay, I found one door that I had inadvertently assigned a class that is invisible (a class I had to make because the Window Tool glazing preferences (Clear, Smoked, etc) don't work (!). See my post "Window Glazing/Style Classes". Another grrr!). But, that's only a single door. There are easily twice as many doors in the schedule as there should be. There are multiple listings for the same ID label. OK, so I deleted that door, and now the file contains ONLY the doors that are in the drawing. I deleted the Door Schedule to start fresh. Pulling out a new Door Schedule... I get the same Schedule as before, and the doors listed are now the only ones in the drawing, but the schedule has listed each door twice, and again, in no order that I can understand (and no apparent way to re-arrange or sort the table). When I choose "Select Item" for Door 1, it shows me the proper door in the drawing. When I choose "Select Item" from the duplicate listing for Door 1, it shows me the same door. Eh? UPDATE: I experimented with deleting the rows in the Door Schedule that are the duplicate doors, and that action deleted ALL the doors in the schedule. So, my questions: 1. Why would the schedule be listing each door twice? 2. How can one re-sort a database-driven worksheet? Thanks,

I considered that I had preliminary layers that had floor plan layout options for my client, and that those layers contained doors. So, I made a new version of the file and deleted all the layers that contained extraneous doors, then went through and double checked to assure that I had just the doors I wanted and then re-imported the schedule (from the "Architectural Reports.vwx" file, as instructed in the manual). I also deleted the existing Door Schedule Worksheet from the file. The resultant new Door Schedule chart still showed doors from an early version of the file that not only had been deleted from the layers on which they were initially place, those layers don't even exist in this file (!), as they were also deleted. And the doors are not listed in numerical order (according to ID label), which is what I would have expected. All very curious. I did find the "recalculate" option (in the actual worksheet, a drop-down sub-menu on the worksheet itself), but that resulted in the same list. I will now try your suggestion, Jeff. What you indicate makes sense to me?that the doors shouldn't show up if they aren't in the file, which is the case and why this is so baffling. More in a moment. Thanks for the input so far.

I've just placed a door schedule, and there are a huge number of doors on there, many of which have long since been deleted from the drawing. Also, they are in no order whatsoever. Is this normal? Is this what this Report is supposed to do? It seems useless to have a tool that supposed to simplify workflow, when it in fact, increases workflow, if I have to go in and try to figure out which doors are the ones actually in the drawing, and then manually put them into order. I could do this faster with pen and paper and paste it on my drawing. Hmmm. Anyone have any idea why the Report is listing doors that don't exist in the drawing? Anyone else have this trouble?

Even with Pat's suggestion? I'm pretty sure it won't work if the window is not properly placed in a wall. Can you re-create the problem in a fresh file? I'd try that with a new wall section, and window settings set up as described earlier. And, until you go through the process of setting the glazing class, as described in my earlier post, the glazing itself will be opaque.

Tim, to solve your trouble with the windows (frame, jamb and sills) being filled solid, be sure that you have a class assigned to the windows, and that class reflects the attributes that you want for your windows. For example, if you want your frames to be colored, then make a new class, set the fill color to solid, and select the color you want. Then, assign that class to each window (you can also set the default by double-clicking the Window Tool, then clicking the "Settings" button to set all the attributes of all subsequently placed windows. The glazing setting (In the "View" subsection of the Window Prefs) seems to be a sticky bit. See my post today "Window Glazing/Style Classes". I have come up with a solution for the glazing, but it's still frustrating that a new transparent class needs to be created and assigned because the existing clear attribute option in the Window Preferences pane doesn't work. At least this is the case for my install. Yours may be working. Is it?

Bug or Nobug?? When I select any of the glazing options in the Window Tool Preferences, there is no change in the glazing of a placed window (nor a new window). The glazing remains an opaque fill. Yes, the window in question is selected. So, to work around this, I created a window glazing class with an opacity of 0% and selected that in the "Use Class" option of the glazing. But then, I had to type in the class name exactly (instead of having an option to select from the list of existing classes, as intuition would suggest). Anyone else have this trouble? Any solutions (besides the one I came up with)? There seems to be a post about this today (Tim Perks' "Filled Windows?"). The solution offered therein does not work, hence this post (but also because I've been frustrated by the glazing settings bit not working). Thanks!

I used to have this trouble with having to log in twice on this forum. Ever since switching from Safari to Firefox 3, the problem has disappeared, so I'm inclined to believe that it was a browser-related issue (for me, anyway). I have noticed other idiosyncrasies with Safari. I think Firefox adheres to the DOM much better.