Miguel Barrera

First, what you are calling a 3D polyline is actually defined in VW as a NURBS curve. Having said that, I think the best solution would be to create the 2D polyline first and then convert it to a NURBS curve. Creating the NURBS curve from the start would be a very complex operation to get the desired roundness, which depends on the weight of each vertex. The following is a 90 degree 2D arc with a 100 radius that I converted to a NURBS curve: tempHandle := CreateNurbsCurve(100.00, 0.00, 0.00,TRUE,3); AddVertex3D(tempHandle, 100.000000000000000, 58.578643762690483, 0.000000000000000); AddVertex3D(tempHandle, 58.578643762690483, 100.000000000000000, 0.000000000000000); AddVertex3D(tempHandle, 0.000000000000000, 100.000000000000000, 0.000000000000000); NurbsSetWeight(tempHandle, 0,0,1); NurbsSetWeight(tempHandle, 0,1,0.804737854124365); NurbsSetWeight(tempHandle, 0,2,0.804737854124365); NurbsSetWeight(tempHandle, 0,3,1); NurbsSetKnot(tempHandle, 0,0,0); NurbsSetKnot(tempHandle, 0,1,0); NurbsSetKnot(tempHandle, 0,2,0); NurbsSetKnot(tempHandle, 0,3,0); NurbsSetKnot(tempHandle, 0,4,1); NurbsSetKnot(tempHandle, 0,5,1); NurbsSetKnot(tempHandle, 0,6,1); NurbsSetKnot(tempHandle, 0,7,1); If you search for "NURBS", you will find a few sites that give a good explanation of the theory behind its construction.

I fully understand what the perceived problem is since I do script programming and use extrudes extensively on my plug-in objects. I am aware that I should apply a class to the profile objects and not the extrude itself which is typically assigned to the default "None". I understand that you want the profile object(s) to automatically get the class assigned to the extrude but what if the profile consist of two polygons and you want one to be yellow and the other red? In your scheme, you will need to create two extrudes with different classes. In the current behavior, you assign the different classes to each polygon and then extrude both at once. I do not see a problem with the current behavior because as long as I am aware which part needs to be classed, I will get the expected visual attributes.

If you assign the same class to the extruded object then you can make changes to them globally. So rather than changing the class name I would change the attributes of the current class or rename the class if desired. Why different class? It gives you the flexibility to assign the extrude to a master class (structural) and the profile object to a sub-class (stud, column, steel beam, etc.).

I do not know the python syntax but is None equal to NIL (empty handle) in vectorscript? Also, there might be parameters that need to be initialized with SetRField(cam,recName,fldName,fldValue).

PROCEDURE Set3DRot( h :HANDLE; xAngle :REAL; yAngle :REAL; zAngle :REAL; xDistance :REAL)Coordinate); yDistance:REAL (Coordinate); zDistance:REAL (Coordinate)); The angles are rotations about the x,y,z axes at point (xDistance, yDistance, zDistance). Assuming that you create an I-beam vertical extrude at (0,0,0) on the x-y (top) plane and the web along the y-axis, and you want to rotate it so it is horizontal along the x-axis. First, you need a 90 degree rotation about the z-axis, which is defined as the axis perpendicular to the x-y (top) plane, to align it along the x-axis. Second, you need a 90 degree rotation about y-axis to bring it down from vertical to a horizontal orientation. So in one step, the function will be written as: Set3DRot(h,#0d,#90d,#90d,0,0,0);

If the 3D object is straight why not just use a simple extrude? The extrude along path will not behave as expected if you don't follow certain rules. 1. The profile must be a group object even for one profile 2. The path must be a nurbs curve and sometimes it does not like having only two points All of which seems more complex when you only need a two point extrude. After it is created then you can rotate and move it where needed

And you also need to declare the variable holding these values as DYNARRAY OF CHAR (2M char?), which is the default type for GetRField / SetRField. If the variable is declared as a STRING, then it will be truncated to 256 char because that is the maximum that a STRING can hold.

In Document Preferences->Display Tab->Adjust flipped text Checking "Adjust flipped text" will orient text in symbols & pio's so that text is always readable.

I would agree with that because it happened to me also. I use the "TrueType To Polyline" menu in a street name sign pio and had to change the script to create the text outside of the reset event. So to be even more specific, it does not work in the reset (draw) event of a pio. In your case, I would look for equivalent functions in vectorscript and replace the DoMenuTextByName calls. The only reason I use the "TrueType To Polyline" menu is because there is no equivalent function in vs but I have managed to do almost all other drawing with vs functions. Is there any particular menu that you use often?

A menu can only be a command script and I did test and confirm that DoMenuTextByName was working in VW 2014 before replying. You should not run, if even possible, any other type such as a tool or object pio's. These types should be added to tool palettes only. It is hard to determine what is the problem without looking at the script. It might be something as simple as missing the Run('script name') at the end or something more complicated.

As I said before, there might be a workable solution but it will take time to test all the different schemes possible. You cannot get events from a cell directly. This can only be accomplished by having a background app listen and receive vw events but the scripting environment does not have this capability yet. I am not really sure if it would be wise to have this capability though since this is how spyware apps work. Another possible workaround would be to include the worksheet in a pio, calculate the position of the cell within the pio when clicked, and show the note in the object info palette for editing purposes. Storing & linking the notes will be another task but it is possible with an external file (text or xml) just like the general notes/callouts are stored.

Expanding on Michael's workaround, you can enter comments in another row or column and then toggle its visibility either manually or with a script for multiple rows/columns by setting the height or width to 0. I do have a script for an estimate worksheet that hides rows of items with zero quantity. Another idea that comes to mind is a symbol or pio assigned to a defined class that will display the comment when selected. Before printing, the symbol or pio can then be hidden by turning off its class.

Neither vectorscript nor python could do this easily because there is no event defined yet for hovering over an object. I have seen some functions for an event enabled tool plug-in but it is not well documented. Even if you could identify the cell where the mouse is, where would you store the note and link it to the cell? That would take a lot of thinking to make it happen.

Yes, it can be done. 1. Add the script to a menu command with the workspace editor. 2. In your Key Command Script call another script with the name of the script. DoMenuTextByName('Script Name',0);

The following is a script that I wrote a few years ago for this case. Although it was done back in VW8, I tested it on VW2014 and still works without changes so it should work on any version since then. It works by running the script and clicking on the text to be added first and then on the text receiving it. When you hover over a text object, the cursor should change and the text should turn red. You can continue clicking and adding text lines to the master text block without invoking the script again and the script will end when you click on an empty space. PROCEDURE AppendText; {DEBUG} VAR sourceClass,targetClass: STRING; sourceHdl,targetHdl: HANDLE; sRed,sGrn,sBlu,tRed,tGrn,tBlu: LONGINT; sourceTxt,targetTxt: DYNARRAY[] of CHAR; FUNCTION GetTextHdl(VAR objClass: STRING; objR,objG,objB: LONGINT): HANDLE; VAR oldClass: STRING; objHdl,oldHdl: HANDLE; pX,pY,mx,my: REAL; red,green,blue:LONGINT; BEGIN oldHdl:= NIL; REPEAT GetMouse(pX,pY); objHdl:= PickObject(pX,pY); IF (objHdl<> NIL) & (GetType(objHdl) = 10) THEN BEGIN IF objHdl <> oldHdl THEN BEGIN IF oldHdl <> NIL THEN BEGIN IF Len(oldclass) > 0 THEN BEGIN SetPenColorByClass(oldHdl); SetClass(oldHdl,oldClass); END ELSE SetPenFore(oldHdl,red,green,blue); END; oldClass:= ''; IF IsPenColorByClass(objHdl) THEN oldClass:= GetClass(objHdl) ELSE GetPenFore(objHdl,red,green,blue); SetPenFore(objHdl,65535,0,0); oldHdl:= objHdl; Redraw; END; SetCursor(SmCrossC); END ELSE BEGIN IF oldHdl <> NIL THEN BEGIN IF Len(oldClass) > 0 THEN BEGIN SetPenColorByClass(oldHdl); SetClass(oldHdl,oldClass); END ELSE SetPenFore(oldHdl,red,green,blue); Redraw; END; oldHdl:= NIL; SetCursor(ArrowC); END; UNTIL MouseDown(mx,my); objHdl:= PickObject(pX,pY); IF objHdl <> NIL THEN BEGIN IF GetType(objHdl) = 10 THEN BEGIN objClass:= oldClass; objR:= red; objG:= green; objB:= blue; END ELSE objHdl:= NIL; END; GetTextHdl:= objHdl; END; BEGIN REPEAT sourceHdl:= GetTextHdl(sourceClass,sRed,sGrn,sBlu); IF (sourceHdl <> NIL) THEN BEGIN sourceTxt:= GetText(sourceHdl); targetHdl:= GetTextHdl(targetClass,tRed,tGrn,tBlu); IF (targetHdl = NIL) THEN BEGIN IF Len(sourceClass) > 0 THEN BEGIN SetPenColorByClass(sourceHdl); SetClass(sourceHdl,sourceClass); END ELSE SetPenFore(sourceHdl,sRed,sGrn,sBlu); Redraw; END ELSE IF GetType(targetHdl) = 10 THEN BEGIN targetTxt:= GetText(targetHdl); targetTxt:= Concat(targetTxt,Chr(13),sourceTxt); IF Len(targetClass) > 0 THEN BEGIN SetPenColorByClass(targetHdl); SetClass(targetHdl,targetClass); END ELSE SetPenFore(targetHdl,tRed,tGrn,tBlu); SetText(targetHdl,targetTxt); DelObject(sourceHdl); Redraw; END ELSE targetHdl:= NIL; END ELSE sourceHdl:= NIL; UNTIL (sourceHdl = NIL) | (targetHdl = NIL); END; Run(AppendText);

I believe this article is not being read correctly. Web software relies a lot on database info to build pages. How you present the data is in the code and the article says that the coding should change based on new technology and it should not perpetuate the same way of entering, presenting, or editing the data. The best analogy I have is the keyboard, representing the old, and the mouse, the new. I remember when I started CADD drawing, everything had to be entered with the keyboard and it was a pain. With the mouse, it is much easier and faster to enter points. The data being fed to the computer is the same but the method used today is totally different. All documents, such as VW files, only contain data. How you present and edit that data is in the code or program. I always read some complaints here that VW should behave more like some other program. That can be accomplished, by reverse engineering, unless there is a patent that protects the inventor from others using such functionality. So VW is indeed preserving the data contained in files without regard to the version. Compatibility in this case means that the code preserves the method used to read a particular version and converts the data to the new file format. This is a separate function from presenting and manipulating the same data, which is what the article makes reference to.

Look at this function: PROCEDURE Rpstr_SetValueStr(name: STRING; value:DYNARRAY[] OF CHAR); This will set values to "named" variables that are basically global to vectorworks even between different sessions. This one is for a string but there are set & get functions for each basic type.

Have you tried using the complete path instead?

Python is, as Matt explained, a more complete language that can make calls to the operating system while Vectorscript is confined to the VW document. The other advantage is that it supports object oriented programming, which is the major concept introduced by C++ and used by newer languages such as java. This means that if the ultimate goal is to create plugins with the SDK, python would be ideal to prototype and debug the basic code since the conversion to C++ would be much easier. To me the greatest drawback to program in python is that there is no reliable way to debug the code other than writing out operation results. The recommended method to use an external program to debug did not work form me and it is the reason I have not gone beyond running the examples provided. You would probably see more development if there was better documentation for all the supported languages including the SDK.

While I agree that VS needs tools to let users interact with PIOs in 3D, I disagree with the first statement that it lacks certain 3D types. 3D polys and extrudes are supported and while a 3D line is not a defined type, you can certainly create one with a 3D poly. The attached image of a traffic signal shows different objects made entirely of extrudes and extrudes along paths of various shapes.

I believe it may have to do with how Booleans are represented as bits. A Boolean is only one bit that has a value of 0 (false) or 1 (true). Since the length of the string evaluates to 0, it translates to false. I know that in lower level languages such as "C", you can use expressions or even functions that evaluate to numerical values in Boolean expressions. A zero is false and anything else is true.

This might be possible if your system has an Excel driver. You will need to become familiar with ODBC and learn how to link it to an excel file. Once it is setup correctly, which includes matching the file with a driver, the file can be accessed by VW or any other program with database functionality. ODBC is just like a translator that makes data accessible through a commom language called SQL.

These are the pio events that I have worked with and tested successfully: kResetObjectEventID = 3; kInitObjPropEventID = 5; {Initialize events} kButtonPressEventID = 35; {Handle button clicks} kOnWidgetDefEventID = 41; {Handle widget visibility & custom popups} kObjAddStateEventID = 44; {Handle changes to parameter values} There are also events recently introduced for tool objects but I have not tested them yet. BTW, all these constants are defined in the C++ SDK if you want to adventure and look at all of them

The only thing I can suggest if you have not done so is to add the paths to all modules under "Script Options". As far as "Import vs" goes, VW should find this module automatically without any adjustments if python was installed correctly at the default path.

I never change the origin for the same problems that you are having. Rather than changing the origin, change the center location for each group iteration. What I also see in the code is that it is missing the text origin. Instead of MoveTo, which only moves the mouse to that location, use TextOrigin to set the location of the text center (justification 2 & 3)