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.
Work Around to Configure Part Properties without Dependence on All Configuration Inputs
Kyler_Walker Member Posts: 168 PRO
I am trying to configure a part number to depend on two List inputs. The part also has a configuration variable input, but I don't want the part number to depend on it. A strategy I have conceived to do this is something like the following. The part number would be configured in the configured properties table using a default value of the configuration variable. A different part studio would derive the part, referencing a document version and using the default value of the configuration variable. A custom feature used in the original part studio would import the second part studio that has the derived part. The custom feature would read the part number of the derived part and write it to the part number of the real part in the original part studio. Can someone please tell me if this type of workflow is viable? I see that getProperty can't be called in custom features, so I'm not sure if I can implement this. Is there another way to get properties of the derived part though? The derived part referencing a version should be able to build completely and independently from the original part studio, right? I don't think I would be created circular references. I would appreciate any suggestions for possible strategies. Thanks!
Here is something that may help. You can getProperty, but it has to be within edit logic, then passed back through your features definition. This has limitations, but it is possible. For example, edit logic only works while the feature is open and active. So it will get the property at that moment, but will not update automatically if it changes in the future; you would need to open the feature again for it to get the property again.
Learn more about the Gospel of Christ (Click here)