Jump to content

Rick Francken

  • Posts

  • Joined

  • Last visited

Everything posted by Rick Francken

  1. Kellie, did you try using "HUngroup" function? I just tested this script on a 3D custom object and on a group of simple shapes, and no dialogs came up. script... procedure scriptmain; var hGr: handle; begin {assuming that a Group is selected...} hGr:= FSActLayer; if hGr<>nil then begin HUngroup(hGr); end; end; run(scriptmain);
  2. raidfibre, If you used 2D polygons instead of 3D polygons, does it make any difference? I've done a lot of thermoforming mold design, and have mostly used 2D polygons or rectangles for the extruded profiles.
  3. So what about people who design molds for thermoformed and injection molded plastic parts? Are you saying that they are all idiots? Or dumb enough to create a mold profile with rounded corners and a 2 degree taper, and running what-if scenarios for molds with corner radii ranging from 1" radius down to square corners? Are you saying they are idiots for trying to reproduce a number of possible toolpaths quickly for a CNC mill cutting with a 2 degree taper end mill? Dumb enough to try something that is faster than editing polyline vertices? If we are designing an injection mold or a thermoforming mold, we are working with tapered extrusions, almost always. And we are working with rounded corners on rectangular shapes, almost always. But sometimes we have to visuallize the difference between a mold with rounded corners and a mold with sharp corners. In Solidworks or Inventor (or most any parametric modeling app), you can drive the corner radii of the profile with one common radius parameter. You can then change that radius parameter to 0 or any other value within reason, and Solidworks or Inventor will update the geometry accordingly. Perhaps you should find out what designers are trying to accomplish before you say we are idiots who are dumb enough to try to do something a certain way. Also, please explain how this is a divide by zero crash.
  4. What are the values in DiamX and DiamY? From your numbers there it looks like DiamX and DiamY values of 1.0" will taper down to 0" right around 13.75" in height. I seem to recall that this would make VW 12.5.0 crash, but 12.5.1 handles it without problem. One guaranteed way to make Vectorworks crash is to set the DiamX and DiamY values to 0, and then try a Tapered extrude. Or for a variation on that, use your rounded rectangle with DiamX and DiamY set to 1.0", create the tapered extrude, then double click the tapered extrude to edit the rounded rectangle, and set its DiamX and DiamY to zero. When you click on Exit, Vectorworks will crash.
  5. I am not arguing that it's a good or easy or preferred approach. It probably should be filed under "Just Because It Can Be Done Does Not Mean It Should Ever Be Done". I agree that the Path Object is the better approach, because Vectorworks manages all the internal behaviors for you. Just wanted to note that adding control point parameters dynamically is possible. Just not easy, and not the best way. I don't know that it matters whether you have one record format for each control point, or all your control point values on one record format, or in a worksheet. The main issue is that if parameters are created dynamically, they probably have to be managed and used dynamically as well...which means a LOT more programming to the PIO.
  6. SYLVAIN, It is possible to do that. I created one that actually worked like that. It takes a bit more coding though. Your PIO needs to be event-enabled. Use the following constants for the widget arguments: kFieldCoordLocX = 10; kFieldCoordLocY = 11; Use the same naming convention as the Parameter Editor, i.e. first control point pair should be "ControlPoint01X" and "ControlPoint01Y", next is "ControlPoint02X" and ControlPoint02Y", and so on. You will have to manage the control points by instance, so plan on setting a unique name for each instance of your PIO. Create a record format specific for each instance of the PIO. Track the control point values in the record format. Structure your code to use the values in the record format to do your drawing. That said, yes it possible. But Petri's suggestion to use a path object might be a better approach. Regards,
  7. DavidH, Can you send me the STEP files? I can convert them to SAT or IGES in Inventor. Regards,
  8. Rick Francken


    Like this? var MessageText: string; begin MessageText:= Concat('First Line', Chr(13), 'Second Line'); AlrtDialog(MessageText); end;
  9. DavidH, So far I've had best success using IGES imports when I am working with solid modeling in VW. That said, try a google search on "STEP IGES Convert" to see if anything comes up. Good luck,
  10. Mike, I don't see anything wrong with your code. I do see the same problem a PIO that uses other PIOs instead of Symbols to redraw. Neither Redraw or ResetObject seem to get it to display properly that first time. It requires at least one "reset" event to happen. I thought I remembered reading a thread in this group some time ago where you could get force a reset by changing the lineweight and then changing it back. You might try searching for that info. Good luck,
  11. Mike, are you willing to show us the script of one of your plug-in objects, that we could see what you have programmed?
  12. Christiaan, try this. In your bad-dwg vectorworks file, bring up the hatch editor dialog from your resource browser. Write down the settings for the Start Point, Repeat, Dash Factor, and Offset...for each level. Export the drawing as either DXF or DWG. Now close bad-dwg, and create a new Vectorworks drawing. Import the DXF or DWG you just exported. Go look at the ANSI35 hatch in the hatch editor, and compare the settings with what you wrote down.
  13. Christiaan, When I exported a DWG and opened it in recovery mode, the following messages showed while loading the DWG: Auditing Entities Pass 1 AcDbHatch(32) Hatch Pattern Too Dense Set Pattern Scale to 1E+001 AcDbHatch(37) Hatch Pattern Too Dense Set Pattern Scale to 1E+001 It looks like your hatch definition is bad. When I looked at it in Vectorworks, the hatch looked OK, but you were zoomed in 409,600%. When you zoom out to 100%, the hatch becomes...dense. Try changing the hatch pattern scale, and see if that makes a difference. Regards,
  14. I'm sorry, but that's just not correct. AutoCAD IS a graphics program, and it is NOT just a line drawing program. As for limitations and graphical drawing options, Autocad has no less limitations than Vectorworks, and far more drawing options. Just about every object you can create in AutoCAD can be created in several possible ways. It is a line drawing program when the user does not know how to use it any other way, but I have received Vectorworks drawings that are also just line drawings. You can build higher level objects that represent real life design elements in both applications...if you know what you are doing. You can do 2D and 3D in whatever appearance you want in both applications...if you know what you are doing. You can export data to other applications in both AutoCAD and Vectorworks...if you know what you are doing. It is not limitations that put a user at a disadvantage, it is their lack of experience with the program, Vectorworks or AutoCAD. Sorry if I come across as defending AutoCAD in a Vectorworks discussion. I do think that Vectorworks is the best CAD tool in a multiple OS environment. And I believe that you can structure your VW designs to be more AutoCAD-ready. Your report needs to include some hard numbers on the cost difference between Vectorworks Architect licenses (with Renderworks), and AutoCAD or Architectural Desktop licenses, including a Windows license. You also need to include the cost of training each of your architects on AutoCAD or ADT. You need to show, if possible, how much your productivity will be lost during the time it will take to get up to speed. And you need to include the cost of hardware to support the move to AutoCAD. I recommend that you avoid statements like "just a line drawing program" and "limitations of the program put the user at a disadvantage" and "lack of graphical drawing options". They will too easily be refuted by the structural, electrical and mechanical engineers who work with you who do use AutoCAD. Regards,
  15. Katie, Thanks for that little tip. I have some Vectorscript wishes that I will submit that way. Cheers,
  16. Petri, how complex are the symbols? Can you export the symbol library document successfully as one single AutoCAD drawing where the AutoCAD block definitions are consistent with the Vectorworks symbol definitions? If you can export an uncorrupted AutoCAD drawing, it might be easier to write a simple LISP or VBA routine that will split them into individual AutoCAD files. Regards,
  17. So that's why you needed to know the VS Texture functions. Great work, Petri! Tikkurila should be giving you a commission or reward for making it easy for designers to specify their product. Cheers,
  18. Hmmm. Well I wrote a DXF exporter and an EJE and Fabtrol KISS exporter for a structural steel application some years ago. There is an IFC XML schema. And it looks like Vectorscript can read and write XML. If somebody will pay me to do it, I can develop an IFC import/export program. Cheers,
  19. If you are going the route of dialogs, have you tried the "GetFileN" function? FUNCTION GetFileN(title :STRING; defaultFolder :STRING; mask :STRING; VAR fileName :STRING) :BOOLEAN; Also, does the "SaveActiveDocument" function work? FUNCTION SaveActiveDocument(filePath :STRING) :LONGINT; I have not tried SaveActiveDocument yet, but I have used GetFileN and passed in a generated file name.
  20. Petri, Are you saving a text file or a VW drawing?
  21. Petri, I did notice two other record formats present when a texture is created, "NNAPreview Object Options" and "NNAShadow Options". It could be that OpenGL relies on these to render correctly, and using the default values of the record format causes the behavior you see. I don't know if this is the case, but you might try testing different value in these records to see what effect they have on OpenGL rendering. (Oh, the joys of meticulous trial and error testing...<g> )
  22. You're welcome. Kind of fun automating a task like that, isn't it? I know I get a kick out of writing software that enables someone to do 100 hours of repetitive work in 5 minutes. I do like the way you structured the script. It is very readable, and looks easy to understand six months from now. Cheers,
  23. Petri, glad you could use it. The Rendering API is a tough one....took me a lot of hours and failed attempts to figure out how to work with textures. And still more to learn yet. But if you can write scripts that generate other scripts for complex polyline creation, you shouldn't have a problem. Good luck,
  24. Petri, When you exported a vectorscript of your plain color texture, did you see the record format "NNAPlain Color"? The trick is to attach this record to your texture and set its color values. Take a look at the script below... {********** Script: MakePlainColorTexture ***********} procedure ScriptMain; const COLOR_FAMILY = 1; PLAIN_COLOR_PROTOTYPE = 6; var hTexture, hShader: handle; rValue, gValue, bValue: string; begin {make sure there is a Plain Color record present} if GetObject('NNAPlain Color')=nil then begin NewField('NNAPlain Color','Family','1',1,0); NewField('NNAPlain Color','Prototype','6',1,0); NewField('NNAPlain Color','Version','1',1,0); NewField('NNAPlain Color','Color','255',1,0); NewField('NNAPlain Color','Color G','255',1,0); NewField('NNAPlain Color','Color B','255',1,0); SetObjectVariableBoolean(GetObject('NNAPlain Color'),900,FALSE); end; {create and name the texture} hTexture:= CreateTexture; SetName(hTexture,(StrDialog('Texture name?', 'fred'))); hShader:= CreateShaderRecord(hTexture, COLOR_FAMILY, PLAIN_COLOR_PROTOTYPE); {set color values in the Plain Color record} SetRecord(hTexture, 'NNAPlain Color'); rValue:= StrDialog('Red Value <0-255>','255'); gValue:= StrDialog('Green Value <0-255>','255'); bValue:= StrDialog('Blue Value <0-255>','255'); SetRField(hTexture, 'NNAPlain Color', 'Color', rValue); SetRField(hTexture, 'NNAPlain Color', 'Color G', gValue); SetRField(hTexture, 'NNAPlain Color', 'Color B', bValue); end; run(ScriptMain); {********** Script: MakePlainColorTexture ***********} Note that there is no error-checking built into this quick-and-dirty script. But you should be able to hook up the mechanism to process the color values you read in from your file. You just need to implement a Code -> Texture Name function, and RGB color conversion function if your R, G, and B values are not 8-bit (0 - 255) values. I haven't tried with the other shader types, but I have a hunch that each shader prototype has its own record format that you would use. Hope this helps you,
  25. Hi Petri, It looks like you can define parameters for your command plugin, and then access them in the plugin script via the "P<Parameter>" convention. To get a reference to the parameter record, you would call GetPluginInfo instead of GetCustomObjectInfo. You can get the parameter names using the GetFldName function in the Database/Record functions category, but the GetRField and SetRField functions do not seem to have any effect on the parameter record for a menu command. If I see anything else I'll post it. Regards,
  • Create New...