Jump to content
David Bengali

Plugin Control Points vs User Origin offset

Recommended Posts

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)



Edited by David Bengali

Share this post

Link to post

Controlpoints should not be affected at all by the origin, as the coordinate values are stored relative to the inner origin of the object, which is always 0.0

Share this post

Link to post

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.








Share this post

Link to post

Yes, quite possibly this is due to the inability to find it's own location.


Do you really need to have an absolute value for the point, or can you use a point relative to the insertion point of the PIO. If you can use a relative value, you will likely be much better off.



Share this post

Link to post

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

Share this post

Link to post

Somewhere in your code you must be modifying the data that is being entered in the OIP and then saving that changed value.  Take a look at all of your pVariable parameters for this field and make sure it is not something you are doing. 

Share this post

Link to post

This is a long standing issue, and I don't think it will be fixed anytime soon.  The control point display in the OIP is affected by the user origin.  What's worse, if you manually enter a value, you can't compensate for the offset.


The workaround is to not actually display the control point in the OIP, and use two distance parameter fields for display.  You use parameter state eventing to keep them in sync: if the user changes the field, move the control point, otherwise calculate the control point position and write to the display field.



  • Like 1

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.

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