Jump to content

Hello Community!

This Saturday, April 11, from 9am – 1pm EDT we will be performing maintenance on the Vectorworks Community Board. During this time, the site will be unavailable.

PeterT

New Bridge Line Tool

Recommended Posts

I have written a Plug-in for a new Bridge Line Tool for my office since the inherent tool is broken.

 

I am sure my code is a bit ugly, but the tool works perfectly in VW 2016.

 

The issue I have is that in VW 2017, the arc of the bridge line sometimes randomly flips to the opposite side of the line.  The arc is ghosted in on the correct side of the line and selectable but the arc draws on the opposite side of the line and is not selectable (see image).  I do not know why this does not happen in 2016, but only in 2017.

 

58e2b0e80567f_ScreenShot2017-04-03at1_17_45PM.png.d42a603ee2156c112634d312189a7c2d.png

 

Here is my code:

***************************************

PROCEDURE BridgeLineNew;

{Parameters:
    LineLength: DIMENSION
    SetCoverWeight: BOOLEAN
    CoverWeight: INTEGER
    Flip: BOOLEAN
}
       
VAR

    bridgelength :        REAL;
    setcoverweight :     BOOLEAN;
    coverweight :         INTEGER;
    flip :                BOOLEAN;
    cursize :            INTEGER;
    R :                    LONGINT;
    G :                    LONGINT;
    B :                    LONGINT;
    P :                    LONGINT;
    ang :                REAL;
    result :            BOOLEAN;
    objn :                STRING;
    objh :                HANDLE;
    objrech :            HANDLE;
    wallh :                HANDLE;
    adj :                REAL;
    swp :                REAL;
    obj :                HANDLE;
    {debug}
    
BEGIN
        
    {retrieve custom object information}
    result := GetCustomObjectInfo(objn,objh,objrech,wallh);

    {if object information was successfuly retrieved}
    IF result THEN BEGIN
        
        {retrieves parameters}
        bridgelength :=        PLINELENGTH;
        setcoverweight :=    PSET_COVER_WEIGHT;
        coverweight :=        PCOVER_WEIGHT;
        flip :=                PFLIP;
        
        IF NOT setcoverweight THEN BEGIN
        
            {Hides cover weight from the Set Cover Weight parameter in the OIP}
            SetParameterVisibility(objh, 'Cover Weight', FALSE);
        END;
        
        {Hides the LineLength parameter in the OIP}
        SetParameterVisibility(objh, 'LineLength', FALSE);        
        
        {Gets current pen attributes}
        cursize:= FPenSize;
        FPenFore(R, G, B);
        P := FPenPatN;
    
        {Sets pen attributes to draw line}
        PenSize(coverweight);
        PenFore(65535, 65535, 65535);
        PenPat(2);
          
        {Sets Line Length}
        Line((bridgelength)*sin(Deg2Rad(45)),(bridgelength)*sin(Deg2Rad(45)));
        obj := LNewObj;
        DelObject(obj);
        
        {Adjusts coverweight for mils}
        adj := (coverweight*.0254);
    
        {Adjusts line start point by 1/2 coverweight thickness}
        MoveTo(adj/2,adj/2);
        
        {Draws Line and shortens length for cover weight thickness}
        Line((bridgelength)*sin(Deg2Rad(45))-adj,(bridgelength)*sin(Deg2Rad(45))-adj);
        
        {resets pen attributes}    
        PenSize(cursize);
        PenFore(R, G, B);
        PenPat(P);
        
        {rotates line to correct orintation}
        RotatePoint(0,0,-45);
        
        {Sets up checkbox in OIP to flip arc sweep}
        swp := 180;
        IF flip THEN swp := -180;
    
        {Draws Arc}        
        ArcByCenter(bridgelength/2,0,bridgelength/2,180,swp);
                
      END;

END;

Run (BridgeLineNew);

***************************************

 

I'm sure there must be a better way to get the line length, but draw a shorter line than the way I did it by drawing a line and deleting it, then drawing a second shorter line.

 

And why does the arc randomly flip, and why only in VW 2017?  Has something changed in 2017 in regards to arcs?

Share this post


Link to post

I  could not make your bridges flip, but I had to guess at the proper parameters to use.

 

Several things I would have probably done differently.

 

1. Rather than have the line length be the entire length to cover, I would probably write the command to start at the intersection and only draw 1/2 of the cover and extrapolate what was on the other side.

 

2. I would probably make it a rectangle (3 point) object instead of a line object. I would then use the third point to determine which way to draw the arc.

 

Can you create a small test file where arcs are flipping the wrong way? I can't get it to do it here.

 

Also, if you are send a script for a PIO instead of a VW file that contains the PIO, please include a screen short of the parameter settings so someone who wants to compile the script and try it knows exactly the parameters that need to be created and what the default values should be.  Also, please try to remove any extraneous code before posting. I ASS-U-MEd that the commented out parameters at the top of the script were correct and then had to go back and change them to include the underscores you used in the actual parameter names.

Share this post


Link to post

Hi Pat,

 

Thanks for having a look at this.

 

Here are the Parameters:

 

58e2eaa83815b_ScreenShot2017-04-03at5_35_18PM.png.b95777bdf7b4d87b5aab7027ef4a4871.png

 

Most of the time when originally drawn, the arc does not Flip.  Also, if down at 90° or 180° it will not flip. But when you draw it on an angle and resize it, it randomly flips.  You sometimes have to resize it several times to different lengths and eventually it will flip, but not in VW 2016, only in VW 2017.

 

As for which way to draw the arc, the Flip parameter checkbox flips the arc just fine.

 

But what I am saying is it sometimes randomly flips the drawn arc even though the ghosted arc that you can select does not flip.  This happens without checking the Flip checkbox in the OIP.  This random flip usually happens when adjusting very small arc lengths, like just over a 9 mil wire on an electrical plan at 1/4" scale

 

Here is a test file, and below it, how it looks on my screen with both objects selected.  The one on the left has flipped, the one on the right is normal.  Both were drawn with the same tool.

 

Bridgeline test.vwx

 

58e2f0b3c8561_ScreenShot2017-04-03at6_00_05PM.png.af185611efeb1f8d09193c9c5853fa60.png

Share this post


Link to post

I see the selection highlighting showing on the wrong side of the object. I didn't understand before that that is what you were referring to as a "flip".

 

I don't understand the last 4 lines of the script. Can you explain what you think is happening in each line starting with the RotatePoint down through the ArcByCenter? It is late and I am probably not thinking right, but why do you need to rotate the line if you don't also need to rotate the arc? It seems to me that either both or neither should need to be rotated to make it work properly. Also, it looks like you are passing a value of 45 radians to the RotatePoint command not 45 degrees. Could that be the problem?

 

Also, you are using both Cover Weight and Cover_Weight and Set Cover Weight and Set_Cover_Weight kind of interchangeably.  I am kind of surprised if the script you sent and the screen shot of the parameters are both correct that you can even get it to compile. I had to adjust so the parameters names in the PIO Settings contain the _ characters to match the assignments to the variables on lines 39 & 40.

 

Hope this helps.

Share this post


Link to post

Peter,

I, too, see the problem, but have no idea why it exists. However, I noticed your object will draw the wrong way based on its rotation, and possibly its position on the drawing. Very weird.  

 

In the OIP, I changed the rotation from 0° to 360° (by 10° increments) and at some values it draws the wrong way. Move the object to a different location and repeat changing the angle, and it will draw incorrectly at different rotation values. I assume there is a bug in the VS code of the ArcByCenter call, but that will take some testing to prove. The problem could also be cause by an interaction between ArcByCenter and the PIO environment. I'll enter a bug and see what happens. I'll try drawing the arc the old-fashioned way and post back.

 

Pat,

Peter draws the LINE at 45° then rotates it back to 0°. He converts degrees to radians properly, so yes, you were presumably tired. I shortened his code and draw the LINE horizontally, but it does not change anything. Here it is for reference. It's shorter, but not better.

PROCEDURE BridgeLineNew;
VAR
    objh, objrech, wallh : HANDLE;
    flip, setcoverweight, result : BOOLEAN;
    coverweight : INTEGER;
    bridgelength, adj, swp : REAL;
    objn : STRING;
    
BEGIN
	{retrieve custom object information}
	result := GetCustomObjectInfo(objn, objh, objrech, wallh);
	
	{if object information was successfuly retrieved}
	IF result THEN BEGIN
		
		{retrieves parameters}
		bridgelength := PLINELENGTH;
		setcoverweight := PSET_COVER_WEIGHT;
		coverweight := PCOVER_WEIGHT;
		flip := PFLIP;
		
		{Hides cover weight from the Set Cover Weight parameter in the OIP}
		IF NOT setcoverweight THEN
			SetParameterVisibility(objh, 'Cover Weight', FALSE);
		
		{Hides the LineLength parameter in the OIP}
		SetParameterVisibility(objh, 'LineLength', FALSE);

		{Gets current pen attributes}
		PushAttrs;

		{Sets pen attributes to draw line}
		PenSize(coverweight);
		PenFore(65535, 65535, 65535);
		PenPat(2);
		
		{Adjusts coverweight for mils}
		adj := coverweight * 0.0254;

		{Adjusts line start point by 1/2 coverweight thickness}
		MoveTo(adj/2, 0);
		{Draws Line and shortens length for cover weight thickness}
		Line(bridgelength - adj, 0);
		
		{resets pen attributes}    
		PopAttrs;

		{Sets up checkbox in OIP to flip arc sweep}
		swp := 180;
		IF flip THEN swp := -180;

		{Draws Arc}        
		ArcByCenter(bridgelength/2, 0, bridgelength/2, 180, swp);
						
	END;
END;
Run(BridgeLineNew);

NSITH*,

Raymond

 

* Not Sure If This Helps

Share this post


Link to post

Pat,

 

If you comment out the RotatePoint(0,0,45);  you will see that the line draws at 45° to the arc, so I have to rotate the line to be in the same orientation as the arc.  ( maybe there is a better way to draw the line so I do not have to rotate it after it is drawn, but I could not find it).  And RotatePoint must assume degrees because it rotates the line 45 degrees.

 

As for the "swp :=180; and the IF flip THEN swp := -180; that is just changing the sweep direction of the arc from positive to negative, which flips the arc to the opposite side of the line when you check the "Flip" checkbox on the OIP (Just like the built-in Bridge Line tool).

 

ArcByCenter just draws the arc.  It starts in the center "bridgeline/2,0" (half the linelength), and the radius is "bridgeline/2" (half the linelength again) and the angle is 180 and the sweep(swp) is a variable ( either 180 or -180 depending on the Flip checkbox).

 

And if the commented out lines are confusing, here is a cleaned up version without comments:

 

PROCEDURE BridgeLineNew;
       
VAR

    bridgelength :        REAL;
    setcoverweight :   BOOLEAN;
    coverweight :         INTEGER;
    flip :                         BOOLEAN;
    cursize :                  INTEGER;
    R :                            LONGINT;
    G :                            LONGINT;
    B :                            LONGINT;
    P :                            LONGINT;
    result :                    BOOLEAN;
    objn :                      STRING;
    objh :                      HANDLE;
    objrech :                HANDLE;
    wallh :                    HANDLE;
    adj :                        REAL;
    swp :                      REAL;
    obj :                       HANDLE;

 

BEGIN

    result := GetCustomObjectInfo(objn,objh,objrech,wallh);

    IF result THEN BEGIN

        
        bridgelength :=        PLINELENGTH;
        setcoverweight :=   PSET_COVER_WEIGHT;
        coverweight :=        PCOVER_WEIGHT;
        flip :=                        PFLIP;
        
        IF NOT setcoverweight THEN SetParameterVisibility(objh,'Cover Weight', FALSE);

        SetParameterVisibility(objh, 'LineLength', FALSE);        
        
        cursize:= FPenSize;
        FPenFore(R, G, B);
        P := FPenPatN;
    
        PenSize(coverweight);
        PenFore(65535, 65535, 65535);
        PenPat(2);
    
        Line((bridgelength)*sin(Deg2Rad(45)),(bridgelength)*sin(Deg2Rad(45)));
        obj := LNewObj;
        DelObject(obj);

        adj := (coverweight*.0254);

        MoveTo(adj/2,adj/2);

        Line((bridgelength)*sin(Deg2Rad(45))-adj,(bridgelength)*sin(Deg2Rad(45))-adj);
        
        RotatePoint(0,0,-45);

        PenSize(cursize);
        PenFore(R, G, B);
        PenPat(P);
        
        swp := 180;
        IF flip THEN swp := -180;
    
        ArcByCenter(bridgelength/2,0,bridgelength/2,180,swp);
                
      END;

END;

Run (BridgeLineNew);

Share this post


Link to post

Raymond,

 

Thanks for the cleanup.  Not sure why I had all the trigonometry in there, but I was having trouble getting the handles at the ends of the arc rather than at the ends of the shorter cover weight line.  I will have to examine your fix as shorter is definitely better.

 

And of course I forgot about Pushing and Popping the attributes, which I have used many times before.  I guess I was just focusing on getting the Arc to draw properly.

 

Thanks,

Peter

Share this post


Link to post

Pat or Raymond,

 

One more question.  Why is it that when you first place the object, or click on the tool preferences button and the "Object Properties" box comes up, the Cover Weight setting is visible, even though the Set Cover Weight checkbox is not checked.  It works properly in the OIP but not on the Object Properties dialog.  Shouldn't they be the same?

 

O.K.,  I just looked at the Nemetschek Bridge Line tool  and it is the same thing with the Object Properties dialog.  I guess the Object Properties dialog ignores the SetParameterVisibility calls and displays all parameters regardless of their visibility settings.

 

Peter

Edited by PeterT

Share this post


Link to post

I don't know about the Properties Dialog box.

 

I think I have a partial solution. Change your values for sap to 179.9 and -179.9.  I don't know why, but I think that using the exact value of 180 is somehow confusing VW. At exactly 180, I think the internal Arc code will have the same end point no matter which direction it is drawn. Yes, the arc angle should tell it what to do, but it appears that it does not always handle it correctly.

 

I tested this with both the original and Raymond's versions and I can't get it to fail here.

Share this post


Link to post

Peter,

I swapped your ArcByCenter() call with the original VS Arc() call and the error persists.

 

I changed this:

		{Sets up checkbox in OIP to flip arc sweep}
		swp := 180;
		IF flip THEN swp := -180;

		{Draws Arc}
		ArcByCenter(bridgelength/2, 0, bridgelength/2, 180, swp);

to this:

		{Draws Arc}
		IF flip THEN
			Arc(0, bridgelength/2, bridgelength/2, -bridgelength/2, 0, 180)
		else Arc(0, bridgelength/2, bridgelength/2, -bridgelength/2, 180, 180);

 using Pat's suggestion worked:

		{Draws Arc}
		IF flip THEN
			Arc(0, bridgelength/2, bridgelength/2, -bridgelength/2, 0, 179.99)
		else Arc(0, bridgelength/2, bridgelength/2, -bridgelength/2, 180, 179.99);

though it really SHOULD work with a sweep angle of 180.

 

Drawing a 180° ARC on a Design Layer and rotating it produces the same problem. It seems VW 2017 has a geometry problem. Bug report to follow.

 

Raymond

 

 

 

You are right about the Object Properties dialog. SetParameterVisibility() only works in the OIP. Dialogs and Palettes are drawn by completely different engines. There are different calls that can be used to hide dialog elements, but we cannot modify built-in dialogs like the Object Properties dialog.

  • Like 1

Share this post


Link to post

I see a number of issues and possible improvements with the script.  Nothing that would cause arc to draw on the wrong side, but cleaning the code should help.

 

Your parameter names are fine: a space in the parameter name translates to an underscore in the code.

 

 

22 hours ago, PeterT said:

IF NOT setcoverweight THEN BEGIN
        
            {Hides cover weight from the Set Cover Weight parameter in the OIP}
            SetParameterVisibility(objh, 'Cover Weight', FALSE);
        END;

 

This can reduce to a single line.

SetParameterVisibility(objh, 'Cover Weight', setcoverweight);

If Set Cover Weight is unchecked, do you want to retrieve the line weight of the bridge object itself?

 

cursize:= FPenSize;
FPenFore(R, G, B);
P := FPenPatN;

You can accomplish this with PushAttrs; and PopAttrs;  Those will save all attributes as well as the active class.

 

Line((bridgelength)*sin(Deg2Rad(45)),(bridgelength)*sin(Deg2Rad(45)));
obj := LNewObj;
DelObject(obj);

I don't understand this section.  It essentially draws a line and then immediately deletes it. You should be able to just remove this.

 

adj := (coverweight*.0254);

Only works if your units are set to mm.  The following will retrieve the document's units per inch setting and multiply accordingly.

adj := coverweight / 1000 * GetPrefReal(152);

Because VW draws the ends of lines as rounded, you may actually be better off without the adjustment factor, as the arc completely occludes the ends of the masking line.

 

{Adjusts line start point by 1/2 coverweight thickness}
MoveTo(adj/2,adj/2);
        
{Draws Line and shortens length for cover weight thickness}
Line((bridgelength)*sin(Deg2Rad(45))-adj,(bridgelength)*sin(Deg2Rad(45))-adj);

I don't see a need to draw a line at 45 degrees and then rotate it into place.  Perhaps this script started as a non-plug-in object?  You can think of the PIO has having it's own coordinate system, with (0,0) at one end of the line and aligned on the angle of the line.  Just draw the line straight from right to left, and don't rotate.

 

RotatePoint(0,0,-45);

Having degrees here should be fine (only the trig commands expect radians), but this command acts on selected objects, and may at times be trying to rotate the PIO itself.  HRotate, which takes a handle, is a safer choice.  But in any case, you don't need it.

 

 

Here is a simpler version of the script:

PROCEDURE BridgeLineNew;
{Parameters:
    LineLength: DIMENSION
    SetCoverWeight: BOOLEAN
    CoverWeight: INTEGER
    Flip: BOOLEAN
}
       
VAR
    bridgelength :        REAL;
    setcoverweight :     BOOLEAN;
    coverweight :         INTEGER;
    flip :                BOOLEAN;

    result :            BOOLEAN;
    objn :                STRING;
    objh :                HANDLE;
    objrech :            HANDLE;
    wallh :                HANDLE;

    adj :                REAL;
    swp :                REAL;
    
BEGIN
        
    {retrieve custom object information}
    result := GetCustomObjectInfo(objn,objh,objrech,wallh);
    {if object information was successfuly retrieved}
    IF result THEN BEGIN
        
        {retrieves parameters}
        bridgelength :=        PLINELENGTH;
        setcoverweight :=    PSET_COVER_WEIGHT;
        coverweight :=        PCOVER_WEIGHT;
        flip :=                PFLIP;
        

		{Hides cover weight from the Set Cover Weight parameter in the OIP}
		SetParameterVisibility(objh, 'Cover Weight', setcoverweight);
        
        {Hides the LineLength parameter in the OIP}
        SetParameterVisibility(objh, 'LineLength', FALSE);        
        
        {Gets current pen attributes}
        PushAttrs;
    
        {Sets pen attributes to draw line}
        PenSize(coverweight);
        PenFore(65535, 65535, 65535);
        PenPat(2);
          
        {Adjusts coverweight for mils}
        adj := coverweight / 1000 * GetPrefReal(152);
        
        {Adjusts line start point by 1/2 coverweight thickness}
        MoveTo( adj/2, 0 );
        
        {Draws Line and shortens length for cover weight thickness}
        Line( bridgelength - adj, 0 );
        
        {resets pen attributes} 
        PopAttrs;   
        
        {Sets up checkbox in OIP to flip arc sweep}
        swp := 180;
        IF flip THEN swp := -180;
    
        {Draws Arc}        
        ArcByCenter(bridgelength/2,0,bridgelength/2,180,swp);
                
      END;
END;
Run (BridgeLineNew);

HTH,
Josh

 

Share this post


Link to post

Update on hiding parameters.  The following was posted to the Vectorscript List  February 18, 2010 by Julian Carr

 

Quote

There seems to be confusion here about parameters and parameter
values. You can't duplicate a parameter, though you can load a
default value for a document using VS. You can't load the default
value for the PIO itself -- it must always be entered manually.

You can make parameters invisible by starting their name with two
underscores. Such parameters will still be visible in the Create
Report dialog though. You can make them invisible there too however,
by setting the alternate name to "__NNA_DO_NOT_CHANGE". You can also
hide or grey them in the OIP only using SetParameterVisibility() or
EnableParameter() respectively.

To make record formats visible/invisible, you can use:

       SetObjectVariableBoolean(GetObject('MyRecordName'), 900, True/False);

 

Share this post


Link to post

Josh,

Thanks for the tips.  Raymond also gave me some of the same information and cleaned up my script.

1 hour ago, JBenghiat said:

This can reduce to a single line.

Already did this in the second posting of my code.

 

1 hour ago, JBenghiat said:

If Set Cover Weight is unchecked, do you want to retrieve the line weight of the bridge object itself?

Not sure what you are asking here.  Just like the Nemetschek Bridge Line tool, I only want to see the Cover Weight field if I check the Set Cover Weight check box. I only want to be able to adjust the cover weight of the straight line. There is no cover weight of the Arc.  The Arc line weight is just set by the document default line weight.

 

1 hour ago, JBenghiat said:

I don't understand this section.  It essentially draws a line and then immediately deletes it. You should be able to just remove this.

The reason I did this originally was that if I drew the shorter Cover weight line first it was putting the object handles at the ends of the shorter line not at the end points of the arc.  So I first drew a full-length line to establish the full-length, then deleted it and drew the adjusted shorter length.  Not sure why this does not happen with Raymond's corrections. But if you comment out the drawing of the first line in my original code, you will see that when the object is drawn, the handles are inset from the ends of the arc.

 

1 hour ago, JBenghiat said:

Because VW draws the ends of lines as rounded, you may actually be better off without the adjustment factor, as the arc completely occludes the ends of the masking line.

 

Not so true. If you draw an Arc of 9 mils and a cover weight of 17 (or more) mils, the ends  of the cover weight line will stick out further than the Arc, and you will end up with white gaps in you wire on each side of the Bridge line. This object is not for just drawing in space, it is for drawing a bridge over crossing wires on an electrical plan.  Wires on an electrical plan are rarely straight, so to cover the curved wire lines you need to bump up the thickness of the cover so that it hides the curving line that it is covering.

 

I really shouldn't even have to be writing this script, but the inherent Bridge Line tool has cover behind the Arc which it should not.  If you want to see what the Bridge line tool should draw, draw one in VW 2014.  That is the last version that drew the Bridge line correctly.  I am still waiting for the powers that be to fix the tool, so I decide to write my own tool.  Maybe most people who draw electrical plans just cross their wires and do not use the tool, but really that is not correct.

 

Also, it is odd that in version 2016, the original tool that I wrote works perfectly. It only has the arc flipping sides in version 2017.

Edited by PeterT

Share this post


Link to post

All,

 

I have gone one better than your suggestions.  I have set my Angle and Sweep to 179.999 and this also fixes the flipping problem.  I realize that a 180 and a -180 sweep get you to the same place but the direction (Positive or Negative) should draw the sweep one way or the other.  This must be a 2017 bug with ArcByCenter as it works fine in 2016 at 180.

Share this post


Link to post

I have some further improvements (though not fixing the sweep angle.

- If Set Cover Weight is unchecked, the arc and the cover have the same weight, which is how the VW plug-in seems to work

- I didn't realize the arc and cover might be different weights.  I use a rectangle of no line weight and shift the arc slightly vertically so that the transition from line to arc is more seamless.

 

FYI, the blue handles are set by the plug-in itself, and are what actually determine the line length.  It was probably just the particular code iteration that made it seem like they were moving.  The only way to change those blue handles is to change the length parameter with a SetRField call.

 

-Josh

 

PROCEDURE BridgeLineNew;
{Parameters:
    LineLength: DIMENSION
    SetCoverWeight: BOOLEAN
    CoverWeight: INTEGER
    Flip: BOOLEAN
}
       
VAR
    bridgelength :        REAL;
    setcoverweight :     BOOLEAN;
    coverweight :         INTEGER;
    flip :                BOOLEAN;

    result :            BOOLEAN;
    objn :                STRING;
    objh :                HANDLE;
    objrech :            HANDLE;
    wallh :                HANDLE;

    adj :                REAL;
    swp :                REAL;
    flipMult :			INTEGER;
    
BEGIN
        
    {retrieve custom object information}
    result := GetCustomObjectInfo(objn,objh,objrech,wallh);
    {if object information was successfuly retrieved}
    IF result THEN BEGIN
        
        {retrieves parameters}
        bridgelength :=        PLINELENGTH;
        setcoverweight :=    PSET_COVER_WEIGHT;
        IF setcoverweight THEN
			coverweight := PCOVER_WEIGHT
		ELSE
			coverweight := GetLW( objh );
        flip :=                PFLIP;
        

		{Hides cover weight from the Set Cover Weight parameter in the OIP}
		SetParameterVisibility(objh, 'Cover Weight', setcoverweight);
        
        {Hides the LineLength parameter in the OIP}
        SetParameterVisibility(objh, 'LineLength', FALSE);        
        
        {Gets current pen attributes}
        PushAttrs;
    
        {Sets pen attributes to draw line}
        PenSize(0);
        FillBack(65535, 65535, 65535);
        FillPat( 1 );
          
        {Adjusts coverweight for mils}
        adj := coverweight / 1000 * GetPrefReal(152);
        
        {Draw the cover}
        Rect( 0, adj / 2, bridgelength, -adj / 2 );
                
        {resets pen attributes} 
        PopAttrs;   
        
        IF flip THEN
        	flipMult := -1
        ELSE
        	flipMult := 1;
        
        {Sets up checkbox in OIP to flip arc sweep}
        swp := 180 * flipMult;
        
        {Adjust arc to curved ends}
        adj := ( GetLW( objh ) / 1000 * GetPrefReal(152) / 2 - adj / 2 ) * flipMult;
        
        {Draws Arc}        
        ArcByCenter(bridgelength/2, - adj, bridgelength/2, 180, swp);
                
      END;
END;
Run (BridgeLineNew);

 

  • Like 1

Share this post


Link to post

I will call it a bug and it SHOULD (MUST) work properly at 180, but I would most likely attribute it to binary math and rounding errors.

 

All of the following are assumptions and conjecture on my part.  Remember that VW2017 moved more of the core drawing to the VGM (Vectorworks Graphics Module). It is possible that the Arc commands final made the move so the under the hood. If I take the original script and change swp back to 180 I can cause an error at an angle of -108.02 to -108.12°.

 

At some point that angle and distance will have to be converted to X and Y coordinates (well maybe not, but in principle). If the fact that the binary value can not exactly represent the value (there will be some data loss that rounding will take care of to a reasonable routing base, but might still exist out say 14 decimal places) put the actual point that the arc is trying to reach on the "Wrong" side of where the end point is supposed to be, then the internal code is probably calculating the position of all the points on the arc going the wrong way even though the "rounded/visible" end points are still at the "correct" location.

Share this post


Link to post

Pat,

 

It appears that if you use  __NNA_DO_NOT_CHANGE as your Parameter alternate name, that makes it permanently hidden.  You do not the seem to be able to make it visible again with SetParameterVisibility(h, 'parameter name', TRUE);  Is that correct?

 

Peter

Share this post


Link to post

Note. All of the variables below are actually proceeded by TWO UNDERSCORES.

 

I don't think you need the __NNA_DO_NOT_Change.  Set your parameter name to  __Cover_Weight.  Set the Alternate Parameter Name to Cover Weight.  Change the definition of overweight to P__Cover_Weight.  Use the following code for the visibility.

 

        IF NOT setcoverweight THEN
        
            {Hides cover weight from the Set Cover Weight parameter in the OIP}
            SetParameterVisibility(objh, '__Cover_Weight', FALSE)
            else
            SetParameterVisibility(objh, '__Cover_Weight', TRUE);

        IF NOT setcoverweight THEN
        
            {Hides cover weight from the Set Cover Weight parameter in the OIP}
            SetParameterVisibility(objh, '__Cover_Weight', FALSE)
            else
            SetParameterVisibility(objh, '__Cover_Weight', TRUE);

The __Cover_Weight parameters will not show up in the Settings dialog box for the PIO and will only show in the OIP when the Set_Cover_Weight box is checked.

Share this post


Link to post

__NNA_DO_NOT_Change prevents a parameter from showing up on lists of parameters. For example, if you were to use Create Report to build a worksheet, that field would be hidden.

 

The double underscore hides a field by default. 

 

A single underscore disables the field from editing. 

 

-Josh 

Share this post


Link to post

25 hours - That's how long it took the engineers to fix it. From Bug Submitted to Resolved in 25 hours. That's not the best I've seen (I think I've seen one fixed in 4 hours), but it's still freaking awesome. The next question is how long will it take to get released? Sadly, that takes a little longer. I'll post back if I hear definitively.

 

Raymond   :-)

Share this post


Link to post

I am surprised to see the original Bridge Line Tool was not fixed in the 2017 SP4 update.  I am sure this is an easy fix for the engineers, but it took me several days to write my own Bridge Line Tool in Vectorscript.

I guess I must be the only one using this tool, as it seems of no importance to anyone else.

 

Besides, I am sure the there were much more important things to fix.

 

I do not care about Bug VB-138438 anymore.  I will just use my own tool.

 

As far as I am concerned, you can just remove the broken Bridge Line Tool from the Application.

 

Thanks to everyone who helped me get my own Bridge tool working, apparently it was not wasted time.

Share this post


Link to post

Have this issue in a different scenario, 2D symbols from VW 2016 containing arcs when imported keep flipping over. 

 

Assume when the bug fix is done it will address this?

 

In the meantime the 179.9° trick does seem to resolve it for my cricket outfields

Share this post


Link to post

Was looking for solution to the Bridge Line PIO problem and found this thread.  I tried the final script above, but it would not compile and I did have time to troubleshoot the problem.  I still have Vectorworks 2014 on my machine so I copied Bridge Line PIO, renamed it Bridge Line 2014.vso and dropped it into 2018 Plug-Ins folder.  That fixed the problem.

 

I actually forgot to delete the existing Bridge Line file, so they were both in the Plug-Ins folder.  I thought that was weird, but it worked for some unknown reason.  If you don’t have a copy of Vectorworks 2014, the 2014 Bridge Line file is attached.

 

When I deleted the 2018 Bridge Line file, the tool showed up missing.  I imagine you can reinstall the 2014 version in the tool palette with the Workspace Manager, but I didn’t bother since it was working.

Bridge Line 2014.vso

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


 

7150 Riverwood Drive, Columbia, Maryland 21046, USA   |   Contact Us:   410-290-5114

 

© 2018 Vectorworks, Inc. All Rights Reserved. Vectorworks, Inc. is part of the Nemetschek Group.

×
×
  • Create New...