Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by MullinRJ

  1. When a selection of objects is sent to the top or the bottom of the stacking order on a layer (Cmd-F or Cmd-B on the MAC), the stacking order of the selection gets reversed. It never worked reliably in my opinion (frequently the top or bottom object would get misplaced), but now it works even worse. OK, I noticed that if you hit Cmd-F twice (Send to Front), the order reverses itself back to the original stacking order (the same is true if you select Send To Back or hit Cmd-B twice), but try using the Send Forward or Send Back menu items and see what happens. The order of the selected objects gets completely jumbled, and NO, hitting it twice or many times does not restore the original order. Does anybody have any issues with this, or is this a feature I need to learn to live with? I am currently using 8.5.2. Is there any improvement in VW9?
  2. MullinRJ

    Etiquette, etc.

    This bulletin board provides excellent feedback for NNA to hear the rants of the installed base, as well as the praises. If they do not respond to this FREE feedback, (some companies pay big bucks for this kind of info), then they may find themselves relegated to a path of slow extinction. I for one do not think this a likely outcome, but given enough time, NNA's responses will dictate how long their customer base will stay loyal. NNA needs to improve their discipline of product development for the system to work better. The reward for their efforts will be an increase in units sold. The lure of providing more service for an added price is a negative incentive. If they are to live up to our expectations, they need to do less - they need to do it better. The laws of economics are strongly at play now - evolve, or go dormant. As simple observation can easily point out, not all evolutionary steps are beneficial to an organism - case in point VW9. With limited resources at hand, NNA must balance their repair efforts with their development efforts, but if they cannot find balance, I pray they err on the side of repair. I don't believe you can get better service just by throwing money at a service provider, especially if it is thrown AFTER the service is provided, as would be the case of increasing the product price. If you were to offer the money BEFORE service is provided, that would be more akin to investing in the company, and can readily be done by purchasing stock. If NNA reads this, I am still using VW8.5.2 and MC6, and will continue to do so until the tone of this bulletin board tends toward praise for their efforts. Please keep the rants coming. I learn much from them and I hope NNA does too. Respectfully, Raymond Mullin
  3. MullinRJ

    Problems w/ hMoveForward & hMoveBackward

    No, the screen redraws automatically at the end of my script, but the objects don't move properly when multiple objects are selected. I did receive a reply from Tech Support. Here it is: <<< Mr. Mullin: > I have been trying to use two new VectorScript procedures to no avail - > hMoveForward and hMoveBackward. In my efforts to determine how these > procedures were functioning/failing, I ran across some other anomalies that > seem to have been around for quite some time. The VectorScript commands > Forward/Backward/MoveFront/MoveBack all have quirks that manifest themselves > when multiple objects are selected. Strangely enough, when the same commands > are invoked using the DoMenuTextByName( ) procedure, slightly different > results occur. In response to you concerns, we have used your test file under VW 8.5.2 and replicated the problems described. However, using VW 9.0, we were unable to replicate the problems save for one issue (described below). The problems described have been corrected. Regarding outstanding issues: 1) With respect to the movement of multiple selected objects using forward or backward commands, VW treats the multiple selection as a single object which is move forward or backward in the stacking order. We have entered this issue in our bug list, but it will not be addressed until VectorWorks 10 at the earliest. 2) The increasing script run times are the result of the undo system storing the object shuffling events in the undo list. You can eliminate this performance penalty by setting the number of undos to zero. This can be set directly from a script by using the function call SetMaximumUndoEvents(). If you should have any questions regarding these or other issues, please feel free to contact us. >>> I was trying to write a script that would insert a point in a POLY when I encountered the problems with hMoveForward & hMoveBackward. I am able to properly insert a point in a POLY except for maintaining the stacking order of the POLY with respect to the rest of the drawing. This is because I need to create a new POLY with the added point and delete the old POLY. Of course new objects are created on top, and I was trying to move the object back in the stacking order where the original was (yes, it is a convoluted approach but it works except for the hMoveBackward problem). I can get by without hMoveBackward, but I can't make a perfectly generic solution without it. I was hoping to make a Plug-In tool with this approach, but, c?est la vie, the brick wall cometh. There was one other minor shortcoming to my endeavor, VectorScript does not have a way to query/set the OPENPOLY/CLOSEDPOLY attribute. All other attributes, including attached records, can be copied to the new object. If anything here is of interest to you let me know. I will be more than happy to share what I've found. Raymond
  4. Has anyone played with hMoveForward and hMoveBackward in VectorScript (new as of 8.5.2)? I am getting varying results in the amount an object moves dependent on the type of object being moved. Symbols behave nicely, whereas Rectangles and Polys do not. I could elaborate on my observations, if anyone is interested, but I just want to know if anyone has tried using these commands?
  5. MullinRJ


    Out of curiosity, how many users use VectorScript on a regular basis? I find it odd that this section of the board is practically unused. Raymond
  6. Caleb, I agree with your concept of focus, but I believe you do not understand our frustration in not being able to EASILY control the modality of the total drawing environment. The keyboard is used extensively in all aspects of drawing - for selecting tools, selecting constraints, selecting the view, AND for entering data. Pressing a keyboard shortcut after data entry has been completed, but before the drawing has been reselected, can lead to a lengthy series of hand movements to recover from the errant keystroke, and that is best exemplified when using the Obj Info Palette. Currently, to accept data, you need to TAB out of the data field when you are finished, but that ALWAYS enters you into another data field. Any key press at this time ERASES the data in the next field and BEGINS entering new data in the new field. This is OK if you want to continue entering data into the next field, BUT, since our "focus remains on the drawing area", as you have so succinctly put it, it would be extremely convenient to the USER to have a keystroke that would FINALIZE the data entry in the OI window. It would also eliminate the need to TAB out of the field to have the data accepted OR to click back into the drawing environment to finalize data entry. By hitting the ENTER key, the data would be accepted as entered and modality would return back to the drawing - no extra mousing required. For modal dialogs, the enter key is used to accept data entry. It can be pressed anytime the data entry is complete - regardless of the field the cursor is in. It would seem a logical extension to preserve this attribute in a data entry palette. Currently, you have to use the mouse to exit the data entry mode of the palette. Where is the "FOCUS" in that? The speed of data entry, the accuracy with which it is entered, and the confidence that it was entered correctly are the three most important aspects that should be considered when evaluating the usefulness of an interface, or as you put it, the FOCUS of the interface. I personally try to avoid using the Obj Info palette for data entry because of its clunky modality. Yes, it is a necessary part of the program, and yes, it adequately displays the data of the object(s) selected; but it is not easy to use as a modifier of object data because data entry CANNOT be terminated gracefully. In short, it really slows me down. I use your software on average 50 hours a week, and have done so for more than 10 years. I feel very qualified in ascertaining when an interface component FEELS clunky, or when it FEELS more cumbersome than previously employed interface components. I do not use the data bar to type in data because it does not have a NICE FEEL, and it does not allow me to communicate my thoughts to your software intuitively. And for the same reason, I try not to use your Obj Info palette. Both interface components DISPLAY data nicely, but they both suffer from a lack of definitively terminating data entry, other than manually clicking in the drawing. Were you to sit at the keyboard and edit hundreds or maybe even thousands of objects in a day's work, you might begin to see the shortcoming of this palette's FEEL. Mr. Retondo (or is it Ms.? I could not tell from the posting) has made an excellent suggestion to remedy this anomaly, and I wish to add my voice to his (hers) in trying to improve the "FOCUS" of this interface element. The ENTER key is the logical choice of keys to terminate and accept data entry. The TAB key is already properly employed to move between fields, and the ESC key makes an excellent choice of keys to exit the palette WITHOUT making any changes. Respectfully, Raymond Mullin [This message has been edited by MullinRJ (edited 07-06-2001).]
  7. Could the RESHAPE dialogs of yore be re-released as a PlugIn Tool (Menu Item)? Use of the OI palette requires a lot of extra mouse work than was needed with the old RESHAPE dialog interface. When editing the sizes or positions of objects, the RESHAPE boxes were a lot faster. It would have to be selectable by a command key to be useful, as extra mouse clicks would defeat its utility. I have been using MiniCad / VectorWorks now for 10 years (since version 2). I know what features I like, and I hate to see them "improved" into obsolescence. So many niceties have gone by the wayside in the march of progress. Ray Mullin
  8. I agree wholeheartedly! The OI palette can be very cumbersome at times and it feels very cluttered. I miss the RESHAPE dialog box from MiniCad days. There was just the information I wanted to edit and it was easy to TAB through the fields and know where I was. AND, it closed when I hit the ENTER key, thus avoiding errant data entry, and extra mouse clicks. I will also post this as a WISH LIST item, but could the RESHAPE dialogs be re-released as a PlugIn Tool? Does anybody else miss the RESHAPE dialogs? Ray Mullin
  9. MullinRJ

    AngleVar/Ang2Vec NOT working

    After further playing with the code, I found that if the pound sign (#) is removed from the Ang2Vec command, it WILL work in VW8.5.2. However, it will NOT work in MC7 or earlier. Thank you gentlemen for such a minor change with major consequences, without OBVIOUS documentation.


7150 Riverwood Drive, Columbia, Maryland 21046, USA   |   Contact Us:   410-290-5114


© 2018 Vectorworks, Inc. All Rights Reserved. Vectorworks, Inc. is part of the Nemetschek Group.