Jump to content

MullinRJ

Member
  • Content Count

    1,307
  • Joined

  • Last visited

Everything posted by MullinRJ

  1. Do you have VW 8.5.2? Most of the PIO's there are unlocked.
  2. When Snap-To-Objects stops working on my machine, I press the Cmd-5 key (Top/Plan View). This seems to jog the software back to proper operation. I have been doing this since VW8.5, but don't know why it is necessary. However, it works. Snapping to objects in Symbols and in Groups is restored when I reset the view to Top/Plan. HTH, Raymond G4/OSX.2.6/VW10.1.2
  3. When you group objects that all have the same class, the group gets created with the same class as the objects. When the classes of the objects differ, the group gets the NONE class. What seems strange to me is when the class to create new objects is set to something other than NONE, a group is still created in the NONE class. I would think it should be created in the current class. Why is that? Raymond G4/OSX.2.6/VW 10.1.2
  4. Hi Katie, I know this has been mentioned before, but is there any hope of your development team making the selection behavior user selectable? I, for one, would greatly appreciate being able to work the old way, but having a choice would be the best of both worlds. Thanks, Raymond
  5. I am using a Logitech Wireless Mouse, w/ 2 buttons and a scroll wheel, VW 10.1.2, OSX.2.6. Using the mouse wheel, scroll and zoom both work wonderfully, and no setup was required on my part. A really nice touch with zooming is that the screen anchors at the mouse location, so that spot remains fixed as you zoom. Thanks NNA. It's nice. Scroll up/down with the wheel Scroll left/right with Shift-wheel Zoom in/out with Option-wheel
  6. Thanks for looking at it Katie. I have not seen it today and I haven't had to restart the computer. It seems to be working just fine now. Must be operator error. Thank you, Raymond
  7. I am experiencing intermittent behavior using Option-Click-Drag to duplicate an object(s) and move the duplicate to a new location. Option-Click and then Click-Drag seems to work, but Option-Click-Drag doesn't always work. I haven't yet seen a pattern as to what triggers this. Changing the view or the Layer seems to get it working again (I think). Has anyone else seen this? G4-Dual 500 OSX.2.6 VW 10.1.2
  8. iboymatt is right, symbols cannot be scaled. But, they can be placed, then decomposed, and the resulting group can be scaled. Of course, decomposing a symbol will disconnect it from the original symbol definition, but if that is not an issue to you, try using this code fragment in a script or a PIO. It should get you going in the right direction. HTH, Raymond code: VAR SignalName :String; X, Y, Rot, ScaleFactor :Real; . . . Symbol(SignalName, X, Y, Rot); DoMenuTextByName('Convert to Group Chunk', 1); ScaleFactor := GetLScale(GetLayer(LNewObj)); Scale(ScaleFactor, ScaleFactor);[/code]
  9. It only seems to happen with Rect's that have their bottom right corner at the origin. I tried it with a square and a rectangle, same result. The culprit seems to be the conversion to Poly. This step is performed implicitly just before the RotatePoint() is executed. Try using the menu "Convert To Polygons", and you will see the same problem. It only seems to happen to Rects that have their bottom right corner at the origin. When converted to a Poly, the 4th point is the one that is omitted. It is definitely a bug, not necessarily with VS, but with VW. My best suggestion at this time is "Don't do that". If you must, move it before you rotate it, then move it back. As long as Point2 (the lower right point) is not at the Origin, you should be OK. Raymond
  10. quote: does anybody use it by preference I do, though changing the preference default would not bother me, as long as I can set it the way I like. Raymond
  11. Hi Katie, Yes, I agree the Patterns Box does work properly. My concern is in changing a foreground color AFTER the Pattern Fill of solid foreground (FP=2, the third pattern box) is selected. By clicking in the Attributes Palette where it now shows the solid Foreground Color, a color palette pops up. Any color change will modify the Background Color and switch the Fill Pattern to (FP=1, the second pattern box). Reset the Fill to PATTERN to see the result of a color change. If I have set the Fill Pattern to Foreground and the color is Green, changing the color to Blue switches the Fill Pattern to Background (second box) and changes the Background Color, not the Foreground Color, even though I have previously set the Fill Pattern to Foreground Solid (third box). This doesn't seem right to me. The only way I can correctly edit the foreground color is to set the Fill Pattern to PATTERN, change the foreground color there, then re-set the Pattern to Solid Foreground Fill, even though it was already set to Solid Foreground Fill. This prevents VW from changing the Fill Pattern from Foreground to Background. It is a lot of extra clicking to do something that used to work nicely up through MC7. I apologize, I wax verbose again, but I AM more concise than last night. Thanks, Raymond
  12. I thought Trademark was ?, and ? is the Register symbol. What is the keystroke for the former? Thanks, Raymond
  13. Dear VectorMagicians, I just bit the bullet and upgraded to VW10.1 and noticed that something I wished had gone away, hadn't. Since VW8 evolved from MC7, the assignment of SOLID colors and fill patterns using the Attributes Palette has been causing me grief. When an object's Fill Pattern is set to SOLID, changing the color of the object can change its Fill Pattern. More specifically, when an object's Fill Pattern is set as solid FG color (FP=2), changing the color in the Attributes Palette also changes the Fill Pattern to solid BG color (FP=1). The opposite is true of the Pen Pattern, where changing solid Pen colors will change a Pen Pattern that had a solid BG pattern (PP=1) to a solid FG pattern (PP=2). The new color displays, but the Fill or Pen Pattern will have been changed. In my drawings, I go to great lengths to set the Fill Patterns, Pen Patterns, Fill Colors, and Pen Colors for every object. These are used as tags for later processing. There is a definite distinction between a solid Foreground Fill (FP=2) and a solid Background Fill (FP=1) when scripts are testing objects for these attributes. So, having the Fill Pattern attribute changed when it is not desired can have disasterous effects later in my design process. Try this. 1) Draw a Rectangle. 2) Set the Fill Pattern to PATTERN in the PopUp menu. Two color boxes appear in the Attributes Palette to the right of the Fill Preview box, the left color box is for the Foreground Color, the right one is for the Background Color. 3) Set the Foreground Color (left box) to Green, and the Background Color (right box) to Yellow. 4) Using the FILL PopUp menu, set the Fill Pattern to SOLID (The rectangle shows as Yellow - or BG Color. My intuition would have expected the FG color to display as it does with the Pen Pattern). Now, 5) Set the Fill Pattern to PATTERN again. 6) Clicking on the Fill Preview box and select the solid FG pattern (third box in from top left). The rectangle now shows as Green. 7) Click on the Green color in the Fill Preview box and change the color to Blue. The rectangle shows as Blue. Here's where the problem comes in. 8) Set the Fill Pattern to PATTERN again. Notice that the BG color was set to Blue and the FG color (Green) was unchanged. The rectangle's Fill Pattern was changed from (FP=2) to (FP=1) in the process. OUCH! What I wish for is the following: 1) If an object's fill is set to (FP=2), changing the object's color will change the FG color and leave the Fill Pattern and BG color alone. 2) If an object's fill is set to (FP=1), changing the object's color will change the BG color and leave the Fill Pattern FG color alone. 3) When an object is changed from a Patterned Fill to SOLID (via the PopUp Menu), the Fill Pattern should be set to (FP=2 or Foreground color). 4) When an object is changed from SOLID to a Patterned Fill (via the PopUp Menu), the Fill Pattern should be set to (FP=3, the first Patterned Fill). The same 4 behaviors should hold true for Pen Patterns as well. I can still force the Colors and Fill & Pen patterns to the way I need them, through many mouse clicks in the Attributes Palette, but it is very tedious to do what used to be very simple. I know you were trying to simplify the palette for the masses, but you have removed a great deal of control in the process. I wish I could have stated this more succinctly and I hope it is not too confusing. I would be more than happy to elaborate if need be. Please let me know if you consider the program's current behavior intentional. Thanks in advance, Raymond Mullin VW 10.1 - OSX.2.3 Mac G4 Dual 500
  14. BG, Though I can understand your example and your wish, I can see major problems in implementing it from NNA'a point of view. Symbols are efficient containers for having (potentially) lots of objects on the screen, without the overhead of really having those objects. Your request is not unreasonable, but it may require more computing horsepower than most of us have on our desks right now. Consider a symbol with 15 rectangles, circles or polygons, some filled, some not. Now consider having 200 or more of those symbols drawn on a page. To get the performance you desire, VW would need to treat each symbol as the multitude of objects it contains. Redraw times would skyrocket, and everyone would complain. Also, RAM requirements would be much, much higher. So, instead of dealing with 200 objects on the screen, VW would have to deal with 3000 objects. Not the best example, but I hope you can see what I'm getting at. In the simple case you describe, it does seem quite doable, but when taken to extremes, even simple things can be daunting. On another note, I have gotten used to selecting objects as VW has always done, and consider symbols as solid filled objects. At least that is how they react when being selected. My work habits have evolved around this feature, so I, for one, would not like to see it change, but that is just me. As with all modality changes that get implemented, I hope NNA sets them up with preferences, as I really dislike relearning a product I have happily lived with for more than 13 years. Raymond
  15. BG, A Rectangle object is defined by two points, upper left & lower right. The other two points are implied from the first two. This is achieved because the implied points fall on the orthogonal X-Y grid, so the left corner points and the right corner points have the same X values respectively. As well, the top corner points and the bottom corner points have the same Y values respectively. Rectangle drawing primitives, that only require two points to define the shape, are supplied in all OS program interfaces and draw to the screen very quickly. The same shape can be drawn as a Polygon, but to do so would require storing all four points individually, thus taking twice the data space for storage and drawing to the screen somewhat slower. Therefore, the Rectangle is more efficiently stored and drawn than a similarly shaped Polygon. Rotate the rectangle, and now all four points have different X & Y values, so a Polygon data structure must now be used, hence the Rectangle is transformed into a Polygon. Rotating it back does not perform the magic you would wish for, returning it to a Rectangle object. Its rectangleness is forever lost (unless you Undo the rotation). What you desire could be done if a Rectangle object also stored a rotation parameter, but that would require more data storage, and ultimately, slower redraw times. If you need to be able to edit rotated rectangles as you describe, you can program a RotRect object as a PIO, but that would undoubtedly add another layer of complexity to your drawing that you probably don't want. HTH, Raymond
  16. Selecting all objects in a layer/class and locking them would prevent deleting or moving things on that layer/class, but being able to lock a layer/class would also prevent ADDING anything to that layer/class inadvertently. It would also be very quick to toggle as well. Also, if locked and unlocked objects exist on a layer/class, locking the whole layer/class, would leave the object level locking intact. Unlocking the layer/class would return you to the same state you were in previously. I think this would be a very useful feature, and I'd like to see it added in the future. Raymond
  17. Do you have VW 8.x? If you open it from version 8 and save it as v8, then v10 will be able to read it for you. If you don't have v8, and the file is not sensitive, send me the file and I will be happy to save as a v8 file and send it back to you. Raymond
  18. << 2) In the workspace editor, in vw 9.5, if a shortcut is already being used vw tells me which comand is using the shortcut. VW 10 does not do this. It just says the shortcut is unavailable. >> In the same vein, it would be nice if the WS Editor would also ask "Do you want to reassign the shortcut?" This would eliminate the need to manually remove it from the current command and return to assign it to the new command. Raymond
  19. I would like to see first tool mode position be the tool default, and I would like to have the ability to set the order of the modes, even to exclude a mode I never use. I wouldn't mind if I had to use the Workspace Editor to set it up, but if I could actively drag the modes to a new position, and have the program remember the order, I would be very pleased. Raymond
  20. There may be several ways, but I would place the image in a symbol, and place the symbol in your PIO. You can store your image/symbol in a template file that you use to create new documents so it is always in your document, or place it in a "library" file in your VW folder/directory, so you can have quick access to it when needed. HTH, Raymond [ 03-13-2003, 11:57 PM: Message edited by: MullinRJ ]
  21. Am I running a day ahead of this board, or is the clock lagging again? Please check the clock setting. Thanks, Raymond
  22. Hi Chris, First, Copy the script to a text file (cut & paste) and save it to your disk for safe keeping. With program still on you Clipboard, continue... In VW, Short version: 1) Open the Resources Window. 2) Click on the New... button. Choose VectorScript. 3) Name or choose your script palette. Name your script. 4) Paste your script in the window. Click OK. 5) Resize and position your new script palette. 6) Double click on the script name to use it. Long version: 1) Open the Resources Window. If no buttons are showing to the right side of the Resources window, click the "Grow Window" button on the upper right of the Resources window title bar. Eight buttons should be visible. 2) Click on the New... button to create a new script. Choose VectorScript from the list of radio buttons and click OK. 3) If you have no Script Palettes created yet (I assume you don't), VW will ask you to assign a name to one BEFORE the new script is created and named. Then another dialog box will appear asking you to name your new script. Confusing at first, but it gets easier with time. The next time you create a script (in this file) VW will already have a script palette created (you can have more than one) and VW will ask if you want to assign the script to one of the existing palettes or create a new one. Now you name your script and continue. 4) Paste the contents of the program in the script window and click OK. Your new Script palette will be on screen with the new script in it. 5 ) Close the Resources window. Resize and position you new script palette. 6) Select objects in your drawing to be modified and double click the script you just created. HTH, Raymond
  23. The examples in my previous post were made using a document that was converted from an older MiniCad document. The numbers and colors cited were wrong for VW 8, 9 & 10. I have corrected the examples above to be consistent with the current VW color palettes. Raymond
  24. It sounds like you meant to change the Delta-Y value instead of the Y value. That will anchor the selected point and modify the object's size accordingly. [ 02-24-2003, 06:57 PM: Message edited by: MullinRJ ]

 

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.

×
×
  • Create New...