FMA

I think the correct way to go about this would be: PROCEDURE xxx; VAR dx, dy, dz :Real; BEGIN dx:= 2; dy:= 4; dz:= 6; CE_TransformVector(FSActLayer, dx, dy, dz); message(dx, dy, dz); SysBeep; END; Run(xxx); I think the function is supposed to take a coordinate and multiply it with a transformation matrix, the return values will be the new coordinate. However I have tried all kinds of objects, layers etc and the output values always remain the same. I don't know how to get a handle to the matrix. There is a bunch more functions in the category but none of them appear to work with matrices:

Yeah, I can get it to work but I have no idea what the matrix handle is supposed to be. Maybe it's just for internal use.

I have to ask this again, I thought I would get it to work but I still didn't. How is it possible to interrupt/get input during the RunTempTool Function? RunTempTool from the function reference: (This draws a simple temporary line and the function gets interrupted with the first mouse click, so far so good) PROCEDURE Test; VAR pt1, pt2 : POINT; FUNCTION TempToolCallback(action, msg1, msg2 : LONGINT) : LONGINT; VAR pt : POINT; BEGIN TempToolCallback := 0; CASE action OF 3: BEGIN {kOnToolDoSetupEventID} vstSetHelpString ( 'Just click once.' ); END; 103 : BEGIN {kToolDrawEventID} vstGetCurrPt2D( pt.x, pt.y ); vstDrawCoordLine( pt.x, pt.y, pt1.x, pt1.y ); END; END; END; BEGIN pt1.x := 0; pt1.y := 0; RunTempTool( TempToolCallback, FALSE ); END; RUN( Test ); But in the Function reference someone also wrote that: If toolCallback returns 0 it exits on first click, if it returns 1 it keeps gathering clicks. The thing is, if I set TempToolCallback:= 1, then the function will just go on for ever. I've tried setting TempToolCallback to 0 and that technically works, but in a very unreliable way. For example: PROCEDURE Test; VAR pt1, pt2 : POINT; key: LONGINT; bool: BOOLEAN; FUNCTION TempToolCallback(action, msg1, msg2 : LONGINT) : LONGINT; VAR pt : POINT; BEGIN TempToolCallback := 0; IF bool = FALSE THEN TempToolCallback := 1 ELSE TempToolCallback := 0; IF KeyDown(Key) = TRUE THEN bool:= TRUE; message(bool); CASE action OF 3: BEGIN {kOnToolDoSetupEventID} vstSetHelpString ( 'Just click once.' ); END; 103 : BEGIN {kToolDrawEventID} vstGetCurrPt2D( pt.x, pt.y ); vstDrawCoordLine( pt.x, pt.y, pt1.x, pt1.y ); END; END; END; BEGIN bool:= FALSE; pt1.x := 0; pt1.y := 0; RunTempTool( TempToolCallback, FALSE ); END; RUN( Test ); This will set the Callback to 0 when a key is pressed (Which will stop it at the next click) but the RunTempTool in VS only appear to be running when the mouse is moved. So the Key input can only be registered while the mouse is moving. Using IF MouseDown(X,Y) = TRUE THEN bool:= TRUE; is even more inconsistent (It is also very unintuitive for the user to move the mouse while for example clicking on a point). Getting Key input during a RunTempTool Function is also generally difficult when the Callback is just 0 and the function simply runs once (I believe that is, as I said, because the function only runs when mouse movement is detected). Has anybody got their head wrapped around this Function or found convenient ways to declare the callback, or found a work around? I've spent quite some time with it now and I would really like to get it. There also appears to be a dimension with the tool events to it that I don't fully understand (CASE action OF 3, 103 etc).

Okay that's very interesting, I was not aware that there are different Functions depending on the distributor.

I don't know what it is called but I mean the little command library that you open when you press the first button at the top left within the VS Script interface (Im using VW 2023). In the category Miscellaneous there is CE_TransformVector(h: HANDLE; VAR dx: REAL; VAR dy: REAL; VAR dz: REAL); with the description: 'Transforms a vector using h TransformMatrix' Maybe it doesn't exist in VW 24

Taking the Plan rotation into account has been a little more challenging but I got it to work now: Checks if Plan is rotated: plan_rotated := GetPref(92); Returns Plan Rotation: PlanRot := GetPrefReal(93); Then a little math: theta:= Deg2Rad(PlanRot); rotX:= X * cos(theta) - Y * sin(theta); rotY:= X * sin(theta) + Y * cos(theta);

In the function list in Vectorworks there are the commands CE_TransformVector and CE_invTransformVector. They appear to be meant to transform a vector using a matrix (Matrix multiplication). It also says it requires the Handle of the transformation matrix (But I don't know how I can get the handle of a matrix). Has anybody ever used these commands? I can't find anything about them online. I think this might be quite a useful feature if it would be working somehow.

Update: It was because of the user origin as you suggested. I could fix it easily with this bit of code: custom_origin:= FALSE; GetOrigin(x_origin, y_origin); IF ( x_origin <> 0 ) OR ( y_origin <> 0 ) THEN custom_origin := TRUE; And inside the TempTool Function: IF custom_origin = TRUE THEN BEGIN x := x + x_origin; y := y + y_origin; END;

Yes I think the documents work with some kind of secondary origin. Maybe from georeferencing (Probably not a rotation because everything is still displayed with the right angles). I will have to look into that.

I have noticed that in certain VW-documents the preview lines called with RunTempTool show at a wrong location, with an offset. The actual objects are implanted at the right location, and the variables used to compute the locations are also all correct. So there must be an issue with the temporary line functions themselves, vstDrawCoordLine vstDrawCoordArc etc. Has anybody experienced this? As of now Ive not been able to recreate whatever causes this to happen in some documents.

@MullinRJ Yes, I don't use backups because I know rewriting all the code will only help me!

@Pat Stanford I never implemented a structure into my code, but atleast the first half of your suggestion I understand and it appears to be quite feasable. I'm working on a different project now, but I will soon come back to this and if I find a good system I will post it here. And @MullinRJ I am sorry to hear that, I hope that didn't happen because of overloading your machine with VS Functions, I also experienced an increased amount of crashes lately and I get a feeling they correlate with running giant loops in vectorworks. Anyway I hope you can retrieve it and I should also backup my scripts it appears.

Hello Raymond. Thank you very much for your reply, I really appreciate it! I will implement the changes you proposed, and maybe I'll find an intelligent way of sorting the input objects before I run the algorhythm in the future. Kind Regards.

Hello Raymond! What I want to do is: I have a selection of 2D-Objects. Each Object will get a shadow-Polygone. If these Polygons overlap they should be combined into one polygone. So I apply the AddSurface() Function to each combination of objects. To ease the process I skip Objects that have already been merged. And I believe to be able to keep track of the handle of the merged objects I have to only apply the AddSurface() Function when the objects actually intersect. This is what that part of the code looks like: FOR iOBJ:= 1 TO totalOBJ DO IF NOT ( shadeOBJ[iOBJ] = NIL ) THEN FOR iOBJn:= 1 TO totalOBJ DO IF NOT ( shadeOBJ[iOBJ] = shadeOBJ[iOBJn] ) THEN BEGIN temphandle:= IntersectSurface(shadeOBJ[iOBJ],shadeOBJ[iOBJn]); IF NOT ( temphandle = NIL ) THEN BEGIN DelObject(temphandle); shadeOBJ[iOBJ]:= AddSurface(shadeOBJ[iOBJ],shadeOBJ[iOBJn]); shadeOBJ[iOBJn]:= NIL; END; END; I'm not a professional programmer and there are probably much more efficient ways to do this. I guess I could separate the Objects into chunks first.

Thanks for the answer. In this case I would have to convert a large amount of objects into lines and then check each line with each line of every other object. I'm not an expert at programming but that sounds like it would take even longer than creating the intersection object and deleting it again. It would be great if Vectorworks could add a command that just checks for the intersection.