Jump to content

David Bengali

  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About David Bengali

  • Rank

Personal Information

  • Occupation
    Theater Designer
  • Location
    United States

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I think I have solved this - It seems VW was not updated to the latest service pack for 2017 on the problem computers, and upon updating, the behavior appears fixed. I should have checked that first. I imagine this is a known bug that is documented in the release notes somewhere.
  2. Well, the relative value is really what I do want, and when I drag the control point, this is what I get. But I also want the user to be able to decide they want that control point, for example, to be 5 feet from the PIO's insertion point, and be able to type 5' and have it go there. It's this case that isn't working out so well. If there were a way to tell the difference between these two different ways in which that parameter can be modified (drag or type), I suppose I could "fix the fix" that vectorworks is applying, but they seem (I think) to be triggering the same event and param change ID. This is on a Linear type PIO, btw
  3. Yes, that should be the behavior, but it is not what is observed. It seems like it may have something to do with the statement on this page: http://developer.vectorworks.net/index.php/VS:Plug-in_Parameter_Types which says: "Control point parameters are sensitive to changes in the user origin of a document, and values displayed in the field will be corrected for any changes in the document user origin." As an example case, I made a file where the internal origin was at 0,0 and created an instance of the plugin object with its origin also at 0,0 If I drag the control point to x=5', y=0', the visible field for the x coordinate is correctly updated to 5' If I type 6' into that field, the control point correctly moves to 6' However, I then moved the User Origin to x=1', y=0' Then, when I drag the control point to 5', all is well, and the field in the OIP shows 5' However, when I type 6' into the field, vectorworks changes the value to 7', and moves the control point to x=7' It is as if the fact that the plugin object appears to now be located at (-1, 0') instead of (0,0) is causing vectorworks to 'correct' the value in the field by adding this additional foot. But only if I type a value into the field. There is a statement on the page linked by Pat which suggests there is some undesirable behavior regarding a plugin object's inability to retrieve its own location relative to the User Origin, but it is unclear if this observed behavior is related.
  4. I am running into an issue related to this topic, wondering if it has come up for anyone else: On the VW install on which I have been developing a plugin, I have had no problems when units are set to Feet and Inches, but when moving the plugin to other computers, suddenly I get an error trying to set the value of Static Text parameters when the units are in Feet and Inches. It looks like somewhere within vectorworks, beyond the level of my plugin's code, there is a problem escaping quote marks. I am building in Python. Here is an example of some code: diag = (width * width + height * height) ** (0.5) vs.SetRField(oh, objname, 'Diag', vs.Num2StrF(diag)) the variables width and height are all the result of calculations based on dimension parameter fields. On the computer where things function correctly, the math works out accurately, and the static text parameter called "Diag" is updated with a value that looks correct, and includes feet and inches quote marks however, on some other computers, I get this error: File "<string>", line 1444 vs.PDiag = '14'1.706"' ^ Syntax Error: invalid syntax There is no direct assignment to the "Diag" parameter in the code, as this error would suggest. Only the SetRField call shown above. This would suggest that somewhere behind the scenes, vectorworks is trying this assignment, and failing because of unescaped quote marks. I do not get this error in other unit modes. And it is strange that I do not get this error on every computer. Any ideas from the group?
  5. Hi, wondering if anyone has any advice -- Sorry for the cross post; I was in the wrong topic area before. I have a plugin that includes a control point that is draggable, but which also exposes one of its coordinate input fields in the OIP to allow the user to type a precise value. When the user origin has been dragged, typed values in this field get offset in ways that lead to "incorrect" values, but dragging the control point behaves as if the current User Origin is the Internal Origin. I imagine I could use GetOrigin() to find the offset and fix this behavior, but how do I detect whether the parameter changed from a drag operation (in which case I should leave it alone) or a typed value in the OIP (in which case I need to fix it)? Or is there a way to get Control Points to only look at the user origin? (the documentation on plugin parameters would suggest not) thanks
  6. David Bengali


    Thread moved
  7. Thanks Patrick, Is there an advised workaround? I am discovering that various third party plugins are showing the same behavior as well and have thus become unusable. best, David
  8. Hi, wondering if anyone has encountered this or knows of a solution: When I enable custom object info palette for a plugin object with vs.SetObjPropVS( vs.kObjXPropHasUIOverride, True ) #8 I find that trying to change the value of radio buttons in the object info palette crashes vectorworks. I have inserted all of the widgets with vs.vsoInsertAllParams() I'm not trying to do anything crazy; I am really just trying to get some separators onto the OIP. I am handling Event 41 as guided by the wiki: ... elif theEvent == vs.kObjOnWidgetPrep: #41 UpdateParametersState() ... def UpdateParametersState(): vs.vsoSetEventResult( vs.kObjectEventHandled ) #-8 Changing the value of other parameters in the OIP, including numeric fields and checkboxes, works fine. Most importantly, I see the same behavior when I try the example plugin provided at http://developer.vectorworks.net/index.php/Python_Sample_Point_Object_(complex) If I click the radio button for Male / Female in this PIO's info palette, vectorworks crashes. This leads me to think there is more going on than bad code in my own object. I am running VW2017 SP4 on Mac OS X El Capitan
  9. Thanks Josh for the pointer to those header files; this listing is super helpful! There are certain things I need to do when my object is reshaped but not necessarily when certain other events are triggered, hence my interest in detecting the reshape event unambiguously. In practice, it has been working fine for me so far to just notice that some reset event occurred, and then see if the length has indeed changed, but it turns out, yes, 18 is the state value that corresponds to this action. At risk of dropping compatibility for earlier VW versions, I guess. My interest in the SDK's ability to notice drag events is really about added control points, and my wish to possibly keep redrawing part of the object as they are dragged for clearer visual feedback, rather than just when the move is done. However, it sounds like that is an advanced topic to return to at some later date.
  10. Thanks, it seems like the SDK may eventually be required. Just curious is there a straightforward way to take a PIO created in python and port it over to the SDK, or even to keep it mostly in python but extend it with the SDK?
  11. initializing variables doesn't seem to prevent garbage on the False case when the event was triggered by a drag of the built-in control points, but in any case, the solution I have gone with is, as Pat suggested, to use hidden parameters to store the old value of LineLength and rotation, and as Josh suggested, to check if these values have changed if an event is triggered but vsoStateGetParamChng returned False. This works fine for my use case, but I still wonder if there is some undocumented constant that corresponds to the state change reflected by this action. It is a little too bad that there isn't one single place where all of the arcane constants in vectorscript are documented. I know there is the appendix of selected tabulated values, but it is incomplete.
  12. Ah, I now understand what you were saying about the state getting cleared. If I put the call to vsoStateGetParamChng before the vsoStateGet calls, I do get True and valid other data in the event of changing a parameter in the OIP. However, for dragging one of the ends of the linear PIO, I get false and garbage data, even if vsoStateGetParamChng is called first.
  13. Thanks Josh, Strangely enough, I seem to be getting false on vsoStateGetParamChng, even when the last state change really was a change to some parameter in the OIP, but also after dragging one of the end points of the linear PIO. Wondering if there is anything I am obviously doing wrong here. Sample code below After a either a linear object reshape, or after a change to a PIO parameter in the OIP, the last alert in the following snippet displays something like didParamChange: False outWidgID: 356515844 OutPrmIdx: -19949 outOldVal: F÷. import vs # event / state constants vs.kParametricRecalculate = 3 vs.kObjOnInitXProperties = 5 vs.kParametricEnableStateEventing = 590 vs.kObjXPropAcceptStates = 18 vs.kObjOnAddState = 44 vs.kObjectEventHandled = -8 vs.kCreatedReset = 0 vs.kMovedReset = 1 vs.kRotatedReset = 2 vs.kParameterChangedReset = 3 vs.kObjectChangedReset = 4 vs.kLayerChangedReset = 5 vs.kExitFromEditGroup = 6 vs.kObjectNameChanged = 7 def execute(): global objname, oh result, objname, oh, rh, wh = vs.GetCustomObjectInfo() theEvent, message = None, None theEvent, message = vs.vsoGetEventInfo() if theEvent == vs.kObjOnInitXProperties: #enable eventing for this plug-in vs.SetPrefInt( vs.kParametricEnableStateEventing, 1 ) #590 result = vs.SetObjPropVS(vs.kObjXPropAcceptStates, True) #18 elif theEvent == vs.kObjOnAddState: #44 message = vs.vsoStateAddCurrent( oh, message ) elif theEvent == vs.kParametricRecalculate: #3 ResetEventHandler() def ResetEventHandler(): global objname, oh if vs.vsoStateGet( oh, vs.kCreatedReset ): #0 vs.AlrtDialog("Object Just Created") if vs.vsoStateGet( oh, vs.kMovedReset ): #1 vs.AlrtDialog("Object Just Moved") if vs.vsoStateGet( oh, vs.kRotatedReset ): #2 vs.AlrtDialog("Object Just Rotated") if vs.vsoStateGet( oh, vs.kParameterChangedReset ): #3 vs.AlrtDialog("Parameter Changed") if vs.vsoStateGet( oh, vs.kObjectChangedReset ): #4 vs.AlrtDialog("Object Changed") didParamChange, outWidgID, outPrmIdx, outOldVal = vs.vsoStateGetParamChng(oh) vs.AlrtDialog("didParamChange: " + str(didParamChange) + " outWidgID: " + str(outWidgID) + " outPrmIdx: " + str(outPrmIdx) + " outOldVal: " + str(outOldVal)) I also see in the wiki the following: (Orso, 2016.05.08): vsoStateGetParamChng returns false after following modifications: on PIO rec set up on move, rot, path reshape layer scale, height, thickness Thus there won't be a state parameter change on move, rot or on copy. outWidgID, outPrmIdx return 0 on move, rot, new obj, alt-drag copy Of course, I am not seeing 0 for those ID's, rather, something that looks like garbage data.
  14. Thanks, yes, I am checking both ParameterChangedReset and ObjectChangedReset, and neither one of these seems to be set when the main control points of the Linear PIO are dragged. Since these are the most basic features of this type of PIO, it seems strange that one would have to resort to the SDK to notice if they have been adjusted, so I assumed I was missing something, but I suppose if Event 3 (parametric recalculate / reset) gets triggered, and none of the states I am checking are set, then I could assume the only remaining option was a change in those control points, and then check stored hidden variables for position, rotation, and LineLength as you suggest.


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...