El Dinyo

Any update on this? We are having stability issues around in the organization dialog as well causing VW to crash. Can't duplicate or change order of design layers in some cases. VB-165189 doesn't looks like it has been addressed in any of the service packs so far.

Just following up on this. This issue has been fixed in Vectorworks 2020 and was a bug that effected 2d path objects in general. (plugin or not). The revision cloud object was also affected by this bug. I have been told that this has been fixed in the latest service pack of Vectorworks 2019 as well.

Including some more info: I am importing a csv file to a vectorworks worksheet.

Part of our workflow involves importing worksheets that in turn updates plugin objects. My issue is with the "Import Worksheet" command. If I import a worksheet, it sporadically changes the number format of various cells. I narrowed it down to some text that i have in some of the cells. More specifically, the "6x Post Min. / 8" Stemwall Min." is causing all the numbers after that to get converted to the wrong number type. You can see the effect on the data below. Obviously, this is a bug that needs to get fixed. Seems like the text is not isolated from the format and is somehow changing the format of future cells. Thanks, Tyler You can see the effect on our plugin object below. This requires is to go in and manually change every one so it has the correct format. Tyler Vectorworks 2020

Importing worksheets takes too long in vw 2019 to the point of users wondering if vw crashed or not. Importing a csv file that used to take ~10 seconds in vw 2017 now takes ~30 seconds. Please fix!

Seems like all 2D Path Objects are broken in this manner in Vectorworks 2019. Vectorworks.....please fix!! This same issue is severely hindering the usability of a custom plugin object that is important to our firm that we have used and developed for 8+ years.

I modify revision clouds with add and subtract surface commands. For some reason, Vectorworks 2019 remembers the previous configuration and will erase the previous modifications made to the revision cloud. This worked in previous versions of Vectorworks. The lastest service pack vectorworks SP4 does not fix the issue. This does not only effect adding and clipping surfaces.... it effects moves. If you move the revision cloud and then add a surface, the resultant revision cloud will reflect the cloud BEFORE you moved it. I had a similar issue before with a 2D Path Plugin Object that I created, but there was no response. I am having the same exact issue with the cloud revision tool. Adding a surface to the original revision cloud: Then i revise the cloud again by adding another surface: The final shape does not reflect the 1st add surface command.

Can 2D Path Plugin event based objects please be fixed? They do not work correctly. When moving objects, it still seems to have the previous location in memory. When using clipping/adding surfaces to object, it still seems to have the previous path in memory and future adds/clips negates the changes that you made previously to the 2d path. Vectorworks support states they don't support custom plugins, but this problem is Vectorworks having bugs in their platform. This was introduced in version 2019. The only half workaround I have found is the force the object to enter reshape mode. However, even this does not work all the time and leaves the user in the wrong mode to continue the workflow. Any help would be appreciated!!

I have a 2D Path Object that has been in use for years and has worked perfectly. It is a 2D Path Plugin Object with extended properties. It is event enabled and allows it to respond to surface operations (add/Intersect/clip surface) which has worked exactly as we wanted it to in Vectorworks 2017 and before. It is based on example 7 in http://www.vectorlab.info/index.php?title=Events (which the Vectorscript Function Reference links to for event enabled objects) Now in Vectorworks 2019, it does not respond properly to add/intersect/clip surfaces (or even just moving the object). It may work properly the first time, but then any operation you try to do after than looks at the original geometry of the 2D Path and not the new geometry or location of the object. The only way to reset it to the new path that you created is by double clicking into the object so that the vertex control points show up for editing. After that the geometery is reset. The bug is present if you just copy and paste example 7 into a plugin and make the plugin event enabled. This is a critical bug for us and would like to get it resolved (or at least a workaround). Thanks

So I copied and pasted the example 7 from Vectorlab for an event enabled 2D plugin that responds to surface editing and it exhibits the same exact issues. This makes me think that something that was introduced in 2018 or 2019 broke the behavior of 2d path objects. http://www.vectorlab.info/index.php?title=Events (go to example 7)

So I tried broke it down to the base 2D Path plugin shown below and I am still having the same problems. It only works after I double click into the object making the vertexes editable. Somehow that resets the location and the new 2D path. I tried resetting the elements using ResetObject( objectHandle :HANDLE); but that has no effect. Only way to truly reset it is by double clicking in. Is the kResetEventID not called anymore on a plugin move or add/clip surface? Maybe that is something I can try. Anyone have any idea why this would stop working in Vectorworks 2019? ( I did not try to use it in Vectorworks 2018) Is it a bug? Also, are there any good replacements for the vectorscript listserv? Is this supposed to be it? That seemed to be invaluable knowledge base and seems to be completely gone now. I know they want to get away from email, but man there was tons of developer content there that now is very lacking. Also the responses were amazing. I make it a surface eligible object in the code below so I can perform the add and clip surface functions on it. You also need to check the checkbox to make the plugin event enabled to make this code work. The actual 2D path is drawn as: Full Code Below: PROCEDURE test; CONST kObjOnInitXProperties = 5; kResetEventID = 3; kObjXIs2DSurfaceEligible = 14; kObjXPropSpecialEdit = 3; kDefaultSpecialEdit = 0; kCustomSpecialEdit = 1; kPropertiesSpecialEdit = 2; kReshapeSpecialEdit = 3; kObjXPropAcceptsMarkers = 10; kObjXPropAcceptsBothMarkers = 3; kObjXPropDefaultPropertyUI = 11; kObjXPropHide3DLocationWidget = 1; kHidePolyWidget = 2; kObjOnWidgetPrep = 41; VAR theEvent, theButton :LONGINT; result :BOOLEAN; objHand, recHand, wallHand, pathHand, dupeHand, dupeHand1 :HANDLE; objName :STRING; objHd2, recHd2, wallHD2 :HANDLE; resultsStatus :BOOLEAN; objName2 :STRING; IsError :BOOLEAN; red, green, blue :LONGINT; start, ending :BOOLEAN; style :INTEGER; size :REAL; opacity :INTEGER; gArrowIndex :INTEGER; gMarkerSize, gMarkerAng :REAL; begArr, endArr :BOOLEAN; BEGIN resultsStatus := GetCustomObjectInfo(objName2, objHd2, recHd2, wallHD2); vsoGetEventInfo(theEvent, theButton); CASE theEvent OF 5: {kObjOnInitXProperties:} BEGIN SetPrefInt( 590, 1 ); result := SetObjPropVS(18, TRUE); result:= SetObjPropVS(8, TRUE); result:= SetObjPropVS(12, TRUE); result := vsoInsertAllParams; result := SetObjPropVS(kObjXIs2DSurfaceEligible, TRUE); result := SetObjPropCharVS(kObjXPropSpecialEdit, Chr(kReshapeSpecialEdit)); result := SetObjPropCharVS(kObjXPropAcceptsMarkers, Chr(kObjXPropAcceptsBothMarkers)); END; 41: {kObjOnWidgetPrep:} BEGIN {vsoSetEventResult( -8 );{kObjectEventHandled} END; 44: {kObjOnAddState} {this is needed for getting event info} BEGIN theButton := vsoStateAddCurrent(objHd2, theButton); END; {Object reset has been called.} 3: {kResetEventID:} BEGIN pathHand := GetCustomObjectPath(objHd2); dupeHand := CreateDuplicateObject(pathHand, objHd2); {set vis of the 2D path object here} SetClass(dupeHand, 'test'); {Set the class of the polygon} SetFPat(dupeHand, GetFPat(objHd2)); GetFillFore(objHd2,red, green, blue); SetFillFore(dupeHand, red, green, blue); GetFillBack(objHd2, red, green, blue); SetFillBack(dupeHand, red, green, blue); SetLSN(dupeHand, GetLSN(objHd2)); GetPenFore(objHd2, red, green, blue); SetPenFore(dupeHand, red, green, blue); GetPenBack(objHd2, red, green, blue); SetPenBack(dupeHand, red, green, blue); SetLW(dupeHand, GetLW(objHd2)); GetMarker(objHd2, start, ending, style, size); SetMarker(dupeHand, start, ending, style, size); GetOpacity(objHd2, opacity); SetOpacity(dupeHand, opacity); GetObjArrow(objHd2, gArrowIndex, gMarkerSize, gMarkerAng, begArr, endArr); SetObjArrow(dupeHand, gArrowIndex, gMarkerSize / GetPrefReal(152), gMarkerAng, begArr, endArr); IsError:= false; IF (IsError = false) THEN BEGIN PopAttrs; { restore drawing environment } END;{END CASE 3} vsoStateClear(objHd2); END; END; {END CASE theEvent} PushAttrs; { save drawing environment} END; {end test} Run(test);

I am trying to update a 2D Path Plugin object from v2017 to v2019 (plugin worked fine in v2017) and I am running into a weird issue. If you move the object from location 1 to location 2, it still has a memory of the original location of the path at location 1 even though nothing shows up there. When try too add/clip surface to edit the 2D path object, it looks at the location 1 for the joins and moves the 2D path back to the original location plus or minus the add/clip surfaces. It works correctly when I double click into the path object to change the shape through vertex tools but that is by FAR a slower method of our workflow. Definately a bug or maybe a method I can use to reset path geometry to the new locations? Thanks for any insights! See below for pics. You can see it ignores the new location and bases the new shape of the object off the old location.