Jump to content

P Retondo

Member
  • Posts

    1,914
  • Joined

  • Last visited

Posts posted by P Retondo

  1. Could we have a key to deselect all objects? Clicking in the drawing space is not always the most reliable method, because groups and other objects can be inadvertantly selected by a click. Besides, a keystroke is often easier and faster.

    In Photoshop the keys are "ctrl + d" and in ACAD it's "esc" twice. I'd suggest a single click of the "esc" key, since that is what we have been advised to use to "clear out" from (i.e., change focus from) the object info palette. It seems like a similar kind of function. If hitting "esc" does two things (change focus to the drawing and deselect all objects), that would be a natural pairing. It's like, "clear the decks of everything ongoing, and get ready for something new."

    By the way, I still think it is more consistent with other software, and even VW's own text tool, to use the number pad "enter" to change focus out of the OIP. Regular keyboard "enter" could do the same thing, since it has no logical use in the OIP anyway. "Tab" and arrows would be the logical choice to navigate fields in the OIP.

  2. quote:

    Originally posted by Robert Anderson:

    What are your class option settings?

    Forgive me, Robert, but I don't know what you mean by "class option settings."

    Update: I work on both a WinXP and a Win2K machine. It appears that the problem involving the "esc" key occurs only with Win2K. I worked for several hours on doors, using "esc", and didn't crash the tools once with WinXP. The first time I tried it again on a Win2K machine, the tools crashed immediately after using "esc."

    There are some other differences between these machines - one (WinXP) has a GeForce4 ti 4200 video card, the other (Win2K) has a GeForce3 ti 200.

    -Pete

    [ 02-24-2003, 12:58 AM: Message edited by: P Retondo ]

  3. quote:

    Originally posted by jfmarch:

    I alwaya use the "~" key (the arrow tool) to switch out of other tools, including symbol placement. There is never a problem.

    Jim, is this a Mac thing? My tilde key (PC) requires the shift, so I wouldn't use that as a shortcut for clicking the mouse.

    Just tried it, and the tilde key on a PC does not act to change focus.

    [ 02-23-2003, 03:31 PM: Message edited by: P Retondo ]

  4. Many good comments here, some of which have been requested often in the past. Some of these requests are to make the programe more like AutoCAD. As much as we hate to think about making VW more like ACAD, I have seen negative reactions on the part of long-time ACAD users too many times to think it wouldn't be important to VW's market share to make the program look and feel more like ACAD - without losing the features and important distinctions that us long-time VW users like.

  5. Bruce, Katie, thanks - I do use 8 selection handles, getting rid of the annoyance is not worth turning that off.

    On the geforce driver, my "version" is a more complicated situation than Katie's single number seems to suggest. The "driver" is, according to my system info, a whole series of files, mostly .dll's, which have numbers that are formatted differently.

  6. Here's the latest on my window and door problems (using the "Window" insertion tool): I have the new door and window .vso files sent by Katie, dated 2-10-03. Using these, I get the following: if I select the tool, I see the dotted "preview" object, I can set the desired preferences, and I can place the window. I can continue placing that window successfully. However, whether or not I place a window, if I hit "escape" I cannot go back and use the insertion tool again. When I select it the tool, I DO NOT see the dotted preview object, and when I place a window it does not appear on the screen, although its parameters appear in the OIP.

    I use "escape" frequently, to change focus from the OIP to the drawing. I have a habit of using it sometimes between selecting tools, also, though it isn't necessary. This appears to be the source of my problem with the crashing window insertion tools. If I do not use "escape," things appear to go properly. Since I almost always use "esc" to exit the OIP, whenever I have edited a window's parameters there, I have ended up crashing the tools. Hopefully this may be a pretty simple bug - ask the programmer to find out why using "esc" crashes the tools.

    I've wondered why a lot of people haven't reported this problem. It may be because most users click on the drawing to change focus from the OIP.

    [ 02-21-2003, 02:42 AM: Message edited by: P Retondo ]

  7. When I change a wall thickness, the wall is enlarged or reduced equally in both directions. This is seldom the desired mode of change. Usually we want it to hold one side or the other fixed, and moving a set of walls to one direction or another by half the change in thickness is quite a chore. It would be very useful to have a way to choose to maintain the center, left or right side of the changed wall. Left or right could be relative to the wall's direction, and when changing more than one wall the program could query for each wall, or allow the user to change all in the same way. One way to get around confusing the terms "left" and "right" would be to have a completely graphic interface: highlight the wall in question, and allow the user to click on "left," "right," or center to select the mode, without actually using any language.

  8. I'm getting some odd black lines, which look like some kind of bounding box, when I am zoomed into a selected object. This only occurs when I'm zoomed in very close, at least 5000%. The larger the object, the smaller the level of zoom required to get these black lines to appear. Sometimes it is just a horizontal line through an object handle, sometimes a horizontal and vertical both through the handle. Anyone else seeing this? Not impossible, but an annoyance when you are trying to see what is going on (the reason for zooming in!)

    VW 10.0.1

    WinXP

    P4 2.2Gh

    768 MB RAM

    geforce4 ti 4200

  9. To add to Chris' comments, if you use OpenGL rendering, a 3d object that has NO FILL will show up as a wireframe object. It will also show up in Renderworks mode, but if you cast shadows the wireframe will also cast shadows as though it were physically made of wire. I haven't tried this, but I would guess you can fill the object and make it semi-transparent, so that it would show up when rendered as a see-through thing. But I have heard of some problems with this - search the RenderWorks area to research that.

  10. Katie, I'll send you a file with a "disappeared" window in it.

    B. Howell: note my procedure for getting the windows and doors to stick (second post in this string). It has been working for me for a week and a half. Hopefully with 10.1 these days will soon be behind us.

    [ 02-14-2003, 12:15 PM: Message edited by: P Retondo ]

  11. Its a longshot, but since I just had a similar scare - it turned out that my problem was having selected Acrobat distiller as my printer. This interfered with opening more than one file.

    VW 10.0.1

    WinXP

  12. We use Adobe Distiller to output .pdf files for email transfer. I just found out that the output prints incorrectly - about 5% too small. I can work around this by setting print setup scaling to 106%, but I wonder if you are aware of this problem, and if you know anything else to do about it.

    I compared a printout directly from VectorWorks, which scales correctly, to a printout from the .pdf file using Adobe Acrobat. The Acrobat file was 5% too small in both directions.

    VW 10.0.1

    WinXP

    HP 4MV

  13. Peter, I was able to dock my palettes one over the other. But it wasn't easy - in fact, I can't tell you how I did it. One thing I did was to customize the workspace so that my tool palettes were a long string! For the other column containing 2 palettes, I tried docking them first in one order, then another, and after a few minutes I finally hit the right combination.

  14. quote:

    Originally posted by Katie:

    Do the doors and windows disappear in the drawing, or just on the screen ?

    When the tool "crashes", can you open a new document and have the tool work, or does it fail here too?

    When clicking on the door/window PIO and you get the pref. dialog box pop up, can you click OK?

    Can you see a dotten line on the screen representing the door/windo PIO ?

    At what point in the process does the door/window become inactive or not visible ?

    Are you sure you have the none class and the other door and window classes set to visible with Class Options set to at least Show Others?

    Was this file created in VW 9.x or VW 10?

    If it was created in 9.5 thru 9.5.3, did you use task manager at all to insert doors and windows?

    Katie:

    When the tools "crash," the following occurs:

    The door or window being edited disappears, and will not print. However, it appears to still exist in the file in some form, and that was confirmed by RA when he was able to "restore" the window in a sample I sent him.

    The tool crash carries across all documents, including opening a fresh new one.

    I can't recall exactly, but I think the preferences dialog box will not open.

    The "dotted line" representation of the window which usually appears before placing it does not appear on the screen.

    The window or door disappears after placing a new value in the PIO object info dialog box and either pressing "Enter" or moving the cursor to another field, OR after checking a box to open detail in one of the field categories.

    I am absolutely certain that this is not a class issue. All classes are visible, checked and double-checked.

    This problem first occurred in a document translated from VW 9.5.2. It also occurs in documents created fresh in 10.0.1. It occurs in a brand new document with nothing else in it, so there are no other objects named "door" or "window" in that basic new document with a single layer.

    To repeat, it is noteworthy that when I place a new PIO object, if I quit VW and reopen the program, the same new object that would have caused the tool to crash can now be edited with impunity.

    Again, I will update you as to whether the revised .vso files you sent me solve this problem. I'm about to find out.

    Thanks for your detailed attention to this problem!!!

    [ 02-12-2003, 01:35 PM: Message edited by: P Retondo ]

  15. Katie, that would be great. If the browser works like the Windows browser, that's something everyone is used to and would be intuitively accessible. I do note the improvement made in the version 10 resource browser, but what you and I are saying makes more sense. As it is, now I have to go looking for the hatches, for example. With a folder structure similar to the older resource window, we could have all of that at hand. If I'm not mistaken, Microsoft makes it very easy to program a Windows style browser using Visual C++.

  16. Katie, I've reported this before - see paragraph 2 of the lead post in this string for a succinct description. When I say "tool crash," I mean that just the tool crashes, not the program. All window and door PIO insertion tools cease to operate until the program is restarted.

    This problem occurs whether one or several files are open. It occurs on the first info palette edit after placing a fresh window or door.

    VW 10.0.1

    Win 2K and Win XP

    [ 02-12-2003, 01:45 AM: Message edited by: P Retondo ]

  17. Katie, thanks - the new PIOs definitely solve the transom problem. I will let you know if they solve the tool crashes. The problem described above by B Howell describes exactly the problem I am having, and as you know my problem is not related to class visibility. So I'd be curious to know if B Howell's problem is class related or not. Also, BH, what are the parameters of your system (VW version, operating system)?

    [ 02-11-2003, 01:26 PM: Message edited by: P Retondo ]

  18. Katie, yes, please send me the better version. I have a pressing need to get a better handle on windows and doors - I don't want to restart my project in v 8.5!

    BTW, I have now tested my procedure pretty well. I can insert a number of doors and windows without a problem, quit the program, then open it and - voila! - the new windows and doors are stable and can be edited in the info palette. The trick is, after inserting any new window or door, do not edit any windows or doors before quitting and restarting VW.

    [ 02-10-2003, 01:51 PM: Message edited by: P Retondo ]

  19. Marc: A few answers:

    Got a few questions:

    What is exactly is the world coordinate system

    **This is the ACAD equivalent of VWs Ground Plane. It is the "unalterable" coordinate system. In ACAD the UCS (user coordinate system) is a "temporary" transformation from the WCS.

    Can objetcs have a seperate different coordinate system?

    **Objects don't hAve coordinate systems. They exist within coordinate systems, and their coordinates vary depending on what coordinate system is currently active.

    Are 3D objects always drawn on the working plane if you don't snap to an object?

    **In my experience, this is so.

    The only good thing about AC is the coordinate system and its ability to be adapted and changed so easily. Which really surprises me because everything else is such a pain the arse.

    This could be a great thing to have in VW especially in 2D.

    **Actually, VWs 3D equivalent, the working plane, works just as well as ACAD's UCS. But there is no 2D equivalent, something a lot of us have been asking for.

    [ 02-09-2003, 02:11 PM: Message edited by: P Retondo ]

  20. Peter, yes, my transom window problem is identical to that with the sliding windows. My major problem, though, has to do with the tools just crashing (see above). Did you experience the kind of bug I describe, where, after you place a window, trying to edit it in the info palette causes it to disappear, and all window and door insertion tools to be disabled? If so, did that problem go away afer receiving the modified PIOs?

×
×
  • Create New...