Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.
First time visiting? Here are some places to start:- Looking for a certain topic? Check out the categories filter or use Search (upper right).
- Need support? Ask a question to our Community Support category.
- Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
- Be respectful, on topic and if you see a problem, Flag it.
If you would like to contact our Community Manager personally, feel free to send a private message or an email.
It's time to update how FeatureScript can control properties
With public MCP access we're about to hit a big wave of custom feature development. One of the most common limitations I hit is in using part properties to do things. I think the Support Team is about to have to field a ton of tickets on this, because the issue is non-obvious, and the thing people want to do (but can't) is reasonable. There are two main issues I see right now:
- If a user sets a property manually, we have to Reset All in order for a feature to set that property. A lightweight solution would be to allow us to reset only 1 property, without clearing them all. Even that could be better though. There's no notification that a feature-set property is being overwritten by a user-set one. It just doesn't work and people have to come to the forums or ask the AI advisor to figure it out. We need better discoverability here, and an easier way to get the Feature back in control.
- It would often be incredibly helpful to have a feature access and actually USE properties during feature regeneration. We could still solve most of the issue for me if these were only used to set other properties. For example, to name the part partNumber~partDescription or simply to write part numbers to a Cutlist Table. I understand that giving carte blanche on property access at runtime opens a pandora's box of edge cases, but I wonder if there is a limited solution that addresses a lot of the reasonable wants without doing that. For example, it would be nice to have a way to use Computed Properties for anything, like the Part Name. However, we'd only want it some of the time. A way to automatically toggle from user-set to computed, then set the computed property would go a long way.
Anyway, I'm sure a better solution than any of my ideas can be found. Devs, if this is on your mind already, let's have a call and I can share some of my experiences.
Comments
-
I've had this point come up a lot as well, and its never fun to say "theres nothing that can be done about this". Reset all is a work around, but its not a great one, and no other workaround exists.
Point 2 has always been a bit odd since you can't read properties during the main body of a feature…but you can during editing logic. The work around it to load the property during editing logic and store in a hidden parameter, but then you're left with functionality that only works when a user pokes the feature, but not during actual regen.www.smartbenchsoftware.com --- Renaissance --- Kestrel -- SmartLink
Experts in Onshape Automation - Custom Features and Integrated Applications0 -
Yes exactly! I've done the editing logic cache thing for a number of client features, but it's always going to feel like a kludge because it is (even if it's the best way currently available to do the thing).
0 -
We are aware of these issues. They're a consequence of how we currently do things (manually set properties are applied via queries to bodies post-regen), but we're having very early discussions about a possible major change to how part studios work that would address these (and even more important issues). Unfortunately a solution is a long way out.
Ilya Baran \ VP, Architecture and FeatureScript \ Onshape Inc2 -
Well, at least the cutlist table could have an option to show properties for entries, its of course rises the question, which propshould take on grouped rows, but say having a sensible default which just displays a first one, or a list of distincts would already be nice to have
1 -
Thanks, Ilya! A good short-term step (assuming it isn't an architectural overhaul) is just allowing us to reset one property at a time instead of all or none. I'm glad to hear a more fundamental solution is on the radar.
0 -
I'm a big fan of how configured properties are highlighted with a yellow border in the properties dialog. And recall I have an enterprise feature request that envision feature-driven properties highlighted the same way, different color is nice. This would be a neat addition to the per-property reset, where if there is a manual override that could warrant a reset that can be highlighted too.
0 -
Yes something more like this would be awesome. I could see value in a way to set a priority on all properties between User, Feature, and maybe API. That way we could decide does a user-setting override the feature or the other way around.
0
