DCarpenter

I copied and pasted an old script into a new one I'm writing and after I save it and close it, the next time I opened it, my script had reformatted it's self into a one line script. All the returns for every line of the script were deleted, so the 80+ line script appears as a one line script that's super long. It still compiles but is a pain to edit and work with. How do I keep this from happening? ...or what did I do? Dave

Thanks Kevin for the link, this is a good start for me. I'll do some experiments and go from there. I appreciate the help.

I tried searching this tech board for 'drape','fabric', and 'clothes' but came up with nothing, so if this topic has been discussed before and you can send me a link to it, I would be very appreciative. I want to create a drape tool, but am having a hard time figuring out the best way to create drape (or fabric) without making a ton of poly's. Has anyone figured out the most optimal way of doing this in Vectorworks? Yes, I know a drape tool exist in VW, but unfortunately I can't access it's code to customize it to my needs. Thanks in advance for helping me out. Dave

OK, it works, but not really. Klinzey said it well when he said 'odd behaviors' So here's the code I'm using: i:=GetDashStyleIndex(False,2,.005,.03); SetClLSN('PP- Projection Cone',i); The first line of code finds/creates the appropriate line type and return the correct index number. The second line sets the line type of the class 'PP- Projection Cone' to the desired index line type. Further down in the code I draw a line that uses the line type on that specific class, and it draws it correctly. Everything is running correctly when I run the PIO, the line that the PIO draws is the correct line type. But when I manually check the class in the drawing after executing the PIO it shows me that the line type for that class HAS NOT changed, it's still the default line type. So I convert the PIO (which ran correctly) to a group and select the line that is drawn correctly and look at it's attributes. All the attributes are class dependent, including the line style, but when I click the line type of that line, it shows me that it is drawn with the default line type, but it's actually drawn in a specified line type from the PIO. Very "odd" indeed, but the PIO runs correctly Thanks Klinzey.

Thanks Kevin, I'll give it a try.

Thanks. I have been able to create a line (object) in my PIO and assign its attributes to be class dependent. What I'm stuck on is how to change the line type of the class to a specific class. I can find the index number of the line type I want using GetDashStyleIndex, but I just cant seem to find the command that changes the line type of the class. SetClLSN doesn't seem be doing the trick. Is there another method to do this by?

Miguel, Thank you for your response. In a blank drawing template I start with two line types. When I make the changes that you mentioned above the 'ls' value is equal to -3, which makes sense since the GetDashStyleIndex will create a line type if that specific one it's looking for isn't found. Unfortunately when that same value gets processed with the SetClLSN command, The class line remains unchanged. Any ideas?

For the life of me, I can't figure out where to select the line type of a new class I created inside a PIO. I'm able to change the Line Style of the class with SetClLSN, The index of the dash style I want is found by using GetDashStyleIndex. Now I need to do the next step and change the class line type to the specific index number, but can't seem to find the 'Set' command I need. Any ideas? i:=GetDashStyleIndex(False,2,.005,.03); {searches/creates for the dash line index number} SetClLSN('PP- Projection Cone',-2); {sets the line style of the class to 'dash line'} Thanks in advance for your help. Dave

Thanks Kevin, I'll give your suggestions a try. For some reason I didn't think it was that simple. It's a nice relief when the solution is easier than I thought. Thanks for your response. Dave

I'm looking for documentation that tells me how to make my PIO work regardless of weather or not the user is working in metric or Imperial units. So if the PIO has to make a move thats 18" but the unit setting for the document is set to meters, the PIO will fail to work properly. I remember seeing it once, but for the life of me, I just can't find it now. Thanks for your time to answer.

Thanks.

Thanks Jim, I am familiar with the flexibility of VW to use either 20" or 20mm as a way of inputting distances within VW, but what I'm looking for is for vectorscripting within a PIO script. If the script calculates something at 18", but the user is working in meters the PIO fails to operate correctly. I thought I remembered a document that explains this but I can't seen to find it. I hope someone out there can help.

I'm looking for documentation that tells me how to make my PIO work regardless of weather or not the user is working in metric or Imperial units. I remember seeing it once, but for the life of me, I just can't find it now. Thanks for your time to answer. Dave

Maarten, Your the best, thank you so much.

When I create a 2D object I have in the Object Info Palette the "Class", "Layer", "Plane", etc. of that object that I can change. Sometimes I prefer to change a 2D objects "Plane" from "Screen" to "3D", but how do I do that with an object I've created within a script? Sounds like an easy enough question, but I just can't find it anywhere. Thanks in advance for your help. Dave

Miguel, I might use two control points. Once again, I always appreciate your input. Thanks. Regarding the GetPtL saga, I only know enough about Vectorsript to get myself in trouble so I don't know if I can speak much into the "event loop" discussion, all I know is it doesn't make sense. Always appreciative of your help, Thanks.

Thanks Josh. This could work! Thanks for the suggestion. I've never used Control Points before, but playing with for just a little bit it looks like it could work. I don't think I'll do the PIO inside a PIO thing. Sound a bit messy. Still would like to know why the GetPt or GetPtL doesn't work, but I guess I'll have to revisit that later. Thanks.

I understand. Our company does a lot of corporate events (large business meeting) that at times want the audience to be seated around the stage in a circular pattern. I'm writing a script that does that. The most important reference point of this script is the center of the circular seating, which is determined by the first click of the rectangular PIO. The second most important point is how far out from the center point you want the seating to start from, that's the point that I want the user to determine using the GetPtL command. I could ask the user to type in this distance as a dimension, but I would rather have the user just click on the screen where they like it to begin for ease of use. Let me know if that helps or if you need me to clarify anything.

Raymond: I got the same results you did when applying the script to a Menu command or tool in the script palette, but it still locks up and crashes when I try using it in a Point or Rectangular PIO. I've also tried the script in VWv10 Designer with the same result. Miguel: You might be on to something. Maybe the GetPt and GetPtL commands were never meant to be used in a PIO. Could it be that the GetPt command can't translate the real world coordinates with the relative coordinates system of the PIO? That would seem strange but you never know. I'm using this command in a PIO to reestablish a central reference point it uses so that the user can refine the PIO to the needs of the project.

Can someone explain why this simple program is crashing my VW? No matter if I change the varible 'pt' to POINT or VECTOR, or if I change the GetPtL to GetPt, it still crashes. On execution of the script it rubberbands a line to my cursor and waits for the next point. After clicking on the screen which should complete the execution of the script, my PIO icon still appears to be depressed and my pull down menus are greyed out. So I click three more random places on the screen and VW crashes. Even the example script for GetPtL on the http://developer.vectorworks.net page crashes my VW. I've tried restarting my computer, zapping the P Ram, still nothing seems to help. Is it just me or does it happen for you too? PROCEDURE TEST2; VAR pt: POINT; BEGIN GetPtL(0,0,pt.x,pt.y); END; RUN (TEST2);

I don't like finding bugs, but I do appreciate the work around solution, I'll make it work for my script. I really appreciate you taking the time to look into my little dilemma. Thanks for all your help. Dave

I created the script below that creates a closed polygon and a rectangle, both with a gradient fill. After execution and converting the PIO to a group, both objects show (in the attribute palette) that they have a gradient fill, but on the screen the gradient only appears in the rectangle. If I select the poly and open the gradient dialog box and click preview the gradient appears. Why doesn't the gradient appear on both objects after the execution of the script. Any ideas? PROCEDURE Gradient1; VAR SegmentIndex:INTEGER; h,i: HANDLE; BEGIN {---------------------------------------------Create gradient} h:= CreateGradient('Black-White'); SegmentIndex:=1; SetGradientData(h,SegmentIndex,0,0.5,0,0,0); SegmentIndex:=2; SetGradientData (h,SegmentIndex,.75,1,255,255,255); {-------------------------------Sets fill pattern to gradient} FillPat(-Name2Index('Black-White')); {-------------------------------------------------Create poly} ClosePoly; Poly(0,0, 0,100, -100,100, -100,0); SetFillOriginPoint(LNewObj,0,50); SetFillIAxisEndPoint(LNewObj,-100,50); {--------------------------------------------Create rectangle} Rect(0,0,100,100); Redraw; END; RUN (Gradient1);

I was finally able to get my gradient to map correctly using: SetFillOriginPoint(handle,AGRAD.x,AGRAD.y); {begining point of the gradient} SetFillIAxisEndPoint(handle,BGRAD.x,BGRAD.y); {ending point of the gradient} but wound up not having to use SetFillJAxisEndPoint(handle,AGRAD.x,AGRAD.y); in my script. Dave

I was finally able to get my gradient to map correctly using: SetFillOriginPoint(handle,AGRAD.x,AGRAD.y); {begining point of the gradient} SetFillIAxisEndPoint(handle,BGRAD.x,BGRAD.y); {ending point of the gradient} but wound up not having to use SetFillJAxisEndPoint(handle,AGRAD.x,AGRAD.y); in my script. Dave

Raymond, Thanks for your response, I apologize for not seeing it earlier. Unfortunately I'm very familiar with the same headaches you had years ago. I'm still in the process of figuring things out but the functions below have been helpful so far. We'll see how far they get me. SetFillIAxisEndPoint SetFillJAxisEndPoint Still figuring things out, I'll keep you updated... Dave