Manipulator Change and Editing Logic working together

EvanReese

I'm working on a feature with manipulators to change some values, and I also want editing logic to change some values when others are changed. I've got them both working independently, but I'm not sure the best way to make them work together. Put another way, my editing logic works when I type a new value, but not when I change the same value by dragging a manipulator. Is there a way to get it working without somewhat re-creating the editing logic code inside the manipulator change function? Whats an efficient way to do this?

konstantin_shiriazdanov

You can always extract the code responsible for this specific behavior into a new function and there wouldn't be duplication. There is a big chance that editing logic is not triggered by manipulator change by design.

konstantin_shiriazdanov

You can always extract the code responsible for this specific behavior into a new function and there wouldn't be duplication. There is a big chance that editing logic is not triggered by manipulator change by design.

EvanReese

ok, that's kind of what I figured. I'll give that a go and let you know if I get stuck.

ilya_baran

Konstantin.  Reading the minds of Onshape developers since 2017. 

MichaelPascoe

@konstantin_shiriazdanov
@ilya_baran

Perhaps Konstantin just answered this, but I have a similar question to Evan's.

Is it possible to store the values from the manipulator change function so that they can be used in the features main function? The manipulator function samples lots of values, not just the final position or the manipulator. I need an array of all of the sampled values, not the final value alone.

If this is possible, what would the solution look like?
Here is a standard manipulator triad so you don't have to start from scratch.
https://cad.onshape.com/documents/18041ec8478a11184256a73c/w/b171058d78486d5e5d4211e3/e/711d2838a330fee3545a6e7b

Thanks!

ilya_baran

@MichaelPascoe
The way to do that would be to have a hidden isAnything parameter that would store, for instance, an array that the manipulator change function would update.  It's not pretty and makes me wonder -- what would you want this for?

MichaelPascoe

Thanks for the advice @ilya_baran

Here is a sneak peak. Looks like it will work!

@Evan_Reese Believe it or not, I actually didn't use Freeform spline for the base code =P. However, it looks so similar, and I was no doubt inspired by the FFS, I'm totally going to reference it anyways.

I threw in a sample resolution so that it will only collect points at the distances you specify

EvanReese

MichaelPascoe said:

Thanks for the advice @ilya_baran

Here is a sneak peak. Looks like it will work!

I threw in a sample resolution so that it will only collect points at the distances you specify

what a madman! this is cool

wayne_sauder

@MichaelPascoe
Wow, that would be an incredible tool for plumbing and wiring if it works as a path for some of those feature scripts. I'll give it a try as soon as you release it.   

MichaelPascoe

That would be a good application for it. However, it will not be able to reference points like Freeform spline can. 

For something like that, it would be sweet to have a variation of FFS with pluming profiles built it. And perhaps the option to have straight pipe segments with specified corner radius.

ilya_baran

Ah, I forgot about the 2D drag of the triad manipulator.  Very nice!

Alex_Kempen

@MichaelPascoe
That’s super interesting! I suppose if you wanted to get cute with it, you could also probably add periodic points using a point manipulator, which would make it possible to do things like easily moving the triad manipulator to previously added sections in order to edit parts of the line, and delete/add new sections where appropriate. 

Also, as a side note, it is also possible to use editing logic to cache certain computations in order to improve performance. This is particularly relevant if there’s a lot of computations that produce a standard FeatureScript result, like if several performance intensive operations are needed to compute the location of some relevant points for a feature. The points can be calculated and saved to a hidden parameter in the editing logic. cutting the regen time of the feature. To prevent confusion arising from configurations not triggering editing logic, UIHint.UNCONFIGURABLE can also be useful.

chadstoltzfus

@Alex_Kempen
This idea is very cool and makes a lot of sense (one of those ideas I'm disappointed I didn't come up with myself). I'm guessing you would also implement some exception handling to check and make sure the hidden parameter hasn't lost it's reference and in the handling just recompute that result? 

Alex_Kempen

@chadstoltzfus Yeah, pretty much. It's a little complicated since editing logic doesn't always run, so some layer of additional error handling inside the feature body in order to check the cached info and ensure its still valid is important. Updating the cache can be done using a dedicated parameter, or it can be done automatically whenever an appropriate parameter changes (i.e. someone adds a new entity). One weird thing I'm not thrilled about is the behavior for clearing a message - I usually set messages to clear when another change is made, but this can lead to confusing situations where a user updates the cache and confirms the feature. Since exiting the feature doesn't trigger the editing logic, they'll still see the cache update success message when they reopen the feature, even if the cache is now out of date. That's why additional exception checking in the feature body can be handy, although it isn't always so easy to do.