# Rick Francken

Member

68

1. ## Ungroup without Dialog box

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. ## Shell solid fails miserably

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. ## Does anyone else know of this...

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. ## Does anyone else know of this...

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. ## adding parameters to a PIO

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. ## adding parameters to a PIO

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. ## .step files...

DavidH, Can you send me the STEP files? I can convert them to SAT or IGES in Inventor. Regards,
8. ## text

Like this? var MessageText: string; begin MessageText:= Concat('First Line', Chr(13), 'Second Line'); AlrtDialog(MessageText); end;
9. ## .step files...

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. ## Redraw problems with custom tools

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. ## Redraw problems with custom tools

Mike, are you willing to show us the script of one of your plug-in objects, that we could see what you have programmed?

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.

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,

15. ## A better wishlist system

Katie, Thanks for that little tip. I have some Vectorscript wishes that I will submit that way. Cheers,
16. ## Basic file operations?

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. ## Tikkurila Paints 2006

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. ## Basic file operations?

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. ## Basic file operations?

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. ## Basic file operations?

Petri, Are you saving a text file or a VW drawing?
21. ## Automated creation of textures?

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. ## Automated creation of textures?

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. ## Automated creation of textures?

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. ## Automated creation of textures?

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. ## Menu command parameter record

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,