Plugin Control Points vs User Origin offset

[David Bengali]

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 

Edited July 5, 2017 by David Bengali

[Pat Stanford]

I am short on time right now to dig it to origins. Have you read the article on origins at Vectorial?  http://www.vectorlab.info/index.php?title=Absolute_Origin  It has pretty much everything you could ever know about origins summarized.

 

 

 

 

[Hippocode]

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

[David Bengali]

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.

 

 

 

 

 

 

 

[Pat Stanford]

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.

 

 

[David Bengali]

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

[Pat Stanford]

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. 

[JBenghiat]

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.

 

HTH,
Josh