Jump to content

Carl Burns

Member
  • Posts

    97
  • Joined

  • Last visited

Posts posted by Carl Burns

  1. I'd also like to see it worked on, to streamline multiple offsets.

    Could the dimension dialogue pop up spontaneously? And, couldn't it contain the last (you name it)..say 10, offset dimensions used, so one could select / reuse a dimension quite easily.

    The same sort of dialogue might work for the Move command, wall thicknesses,...others?

    Carl

  2. Thanks for your quick replies.

    I didn't get the right question across though. I've no trouble accessing the Edit Sheets palette, either through the Saved Sheets, or Resources palettes...

    The problem is (to be more specific): there appears to be no way to (via Edit Sheets) set the Active Class to a class which has (hyphenated) sub-classes. For example: exst-struct; exst-floor; etc. The Edit Sheets palette doesn't display the sub classes, and Active Class can only be set to a class which stands alone (has no sub classes). When a class with sub classes is selected, the change isn't saved.

    Perhaps 8.5.2 was the same way. Can't remember. This is the same issue as "How could one toggle through the class structure, as it's a tree, not a line"

    - Carl

  3. I don't seem to be able to modify saved sheet characteristics by:

    Resources Palette > Saved Sheets > Enter (or double click)

    Changes aren't saved. Also class list only displays the top (root) class. I can't remember how 8.5.2 did this, and don't have it installed at the moment, so I can't check. But it doesn't look right.

    Am I missing something?

    Carl Burns

  4. I'm curious. What's the advantage in your method Petri..you favor "copy" over "save as", and as you said you do the opposite of CipesDesign, whose method is encouraged by the way the OS deals with a "save as"(files the original version and opens the new one).

    I recall a concern about doing "save as" in vectorworks, but haven't heard about this issue in a long time.

  5. I see a difference in printed line weights between two lines with identical attributes, one angled the other horizontal (or vertical). I see this more with one printer(hp4m) than another(hpdj430).

    I recall this as an old topic, and related to the squareness of pixels.

    Can this be rectified? Is it a function of drivers, printers, or the base program? Does postscript printing deal with line weights differently?

    Thanks,

    Carl

    vwa 9.5w98

  6. Yes...It would be great if the (NNA and possibly user) expertise evident here and in the discussion list could be worked into a maintained database of information on systems...combinations of hardware/software/tasks unique for VW users. Some obvious candidates: printing solutions, backup solutions, maybe network solutions.

    My guess: This has been considered and rejected by NNA on a simple cost/benefit basis. Additional income expected / cost to devote space and staff; continuing time to maintain; cost to purchase or make deals for hardware; liability for bad info; liklihood of alienating partner enterprises by reviews, however accurate, etc.

    I think it's a great idea anyhow and would further endear users to the product and company.

  7. This is sort of manual and probably exactly what you're referring to, but: You know about the "use layer colors" (document) preference?

    That's a simple, single switch to do what you're talking about. It obviously has a global (within file) impact though.

    A less fussy, somewhat dumber (dumb=good) option might be to simply cut/paste the required (plan) image as a group, assigning all of it the desired attributes (grey line color). Obviously it wouldn't update automatically, but for this use, that doesn't seem so bad.

    It seems that what we might all like would be to layer-link a set of layers into a target layer, and, while maintaining class colors for display/printing, display the layer linked layers as grey.

    I'm still baffled sometimes at the rules for displaying objects (what their attributes are) enclosed within other objects, as groups, symbols. Perhaps the above can already be done?

  8. Originally posted by Archken:

    "...It seems a lot of programming effort was wasted in creating factory add-ons like VA to help the beginner. I would never use VA. That is NOT the next level. As a loyal and seasoned VW user I'm concerned about the misdirection that VW is taking -- the "featuritus" competitive approach instead of creating stable, quirk-free and bug-free innovations."

    1 - I like this general point and want to support it, based on my experience with VW. I've purchased VA and intend to learn it, try it, and work with it. By its nature though VA (versus VW) seems to consist of many many single purpose tools, each one requiring its own learning curve. From my perspective as a sole practitioner architect, working sporadically with the program, this isn't ideal. That the core tools (VW) are effective and widely useful seems far more important. As the cumulative required learning curve increases, the attractiveness of the program to general users (people who actually draw on the computer maybe 25% of the time) diminishes.

    2 - My experience: "Draw it once" may be fine as a sales' approach, but as a literal plan for design, not workable. Again, my experience, but the design process seeems to be not a straightforward accumulation of detail in a drawing...rather the inevitable drawing and redrawing of plans, elevations, sections to work out ideas. My point is that the plan-based 3d drawing process in VW doesn't yet work for this architect, and I find that I have to construct / design elevations and sections as well as plans. And not only once, but repeatedly. The virtues of CAD and paper/pencil are both considerable in this process. Perhaps "realtime elevations/sections" would, if they could, help address this concern. Don't know.

  9. Originally posted by rcarch:

    "...if you use VA like i do, then you have to have lots of detail sheets at different scale, and then spend the time editing the saved sheets to pull up the correct layers."

    Perhaps "detail sheets at different scales" aren't necessary, just detail layers @ different scales. Use visibility to see/show the different scale layers on a single (or more) resultant multi-scaled sheet.

    Details just need to be located, within each layer, to show up in the right place on the final sheet, when veiwed with all visible layers.

    If drawing all details, even those of different scales, together is convenient, why not do that on a detail layer, scale A, later moving details to other scale layers as necessary via OI pallette. Pretty easy.

    Do you use many layers within each scale group?

  10. I think there are some improvements (the trim tool is quick and easy to use now) and some losses in the trim methods in 9.0.1, for my work. I have seen a lot of wishes for the return of the old control-T (win). I hope NNA can spare some concerted thought on this...there seem to be many sorts of trimming situations and now a number of trimming tools here and there around the program. Not pretending to take the time to do it here, I think it would be great to see the trimming better organized / centralized and extended to handle the requirements people propose.

  11. Exactly.

    Another way I've tried to use them less successfully: to layerlink a plan into a layer of 2d elevations, composed the old-fashioned way, with lines from adjacent plan and/or section. Fine in concept, but the machine (It was W95, P233, VW 8.5.2) kind of bogged down with the layerlink. Interesting that a full copy (not a symbol) of the plan was far less taxing for the program / computer.

    [This message has been edited by Carl Burns (edited 08-03-2001).]

  12. In case anyone else was a little puzzled by this tool: I did a little bit of exploring and the answers (as is often the case) are in the program...

    Double-click on page tool icon returns page to origin; it's easy to move page center to preset loci anywhere; the data bar can be used to enter relative move coordinates.

    One apparent exception: At the first move, the data bar doesn't appear. On subsequent moves, it does appear however. This is not an obstacle though.

  13. The existing command is somewhat inconsistent I think: In "linear" mode, the number you enter yields the number of objects created; in rectangular and circular modes, the same numbers refer to the total end result.

    The command works on the basis of the object center, yet there's no way I know to snap to the center, except for making the object into a symbol and adding a locus at the origin. Could the command show the center by adding a locus and allowing the user to move it? This would address one of the long-standing wishlist items I think.

  14. It seems impossible to control the page location with the move page tool: The move page tool / cursor snaps to objects, but not to the page. Also the page cannot be selected and grouped with a reference object like a locus or line(s). So, once moved, its location is unknown forevermore (in that file)?

  15. Trying to import a small file (48 kb of surveyor's info / 3 acre site)from Generic Cad (AutoDesk) into VWA 9.0.1 I get:

    "Open DWG Library Error 301"

    I don't even get into the import dialogue.

    Trying to open same with IntelliCAD 98 I get:

    "probable bad viewport entity header data"

    Any thoughts? (The same info imports ok via DXF though. I thought the information might be closer to original in DWG though. I don't THINK this is saved in paperspace).

    Thanks,

    Carl

×
×
  • Create New...