Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.

First time visiting? Here are some places to start:
  1. Looking for a certain topic? Check out the categories filter or use Search (upper right).
  2. Need support? Ask a question to our Community Support category.
  3. Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
  4. 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.

Namespaced enums in feature UI's

brooke_spreenbrooke_spreen Member, Developers Posts: 115 ✭✭✭
Can anyone shed some light on why enums cannot be namespaced when used in feature UI's?
Design Engineer | Anerdgy AG


  • konstantin_shiriazdanovkonstantin_shiriazdanov Member Posts: 1,221 ✭✭✭✭✭
    edited December 2021
    Every parameter name in the definition should be unique, no matter what type it is and no matter on what nesting level it is, and enums are not an exception here. The workaround is to handle this manually prepending parameter names with the suffix for example and then deconstructing definition by removing this suffix with replaceString().
    You probably meant something different, I think they just need to be in the global feature studio scope. I found it generally to be a good practice to keep type definitions in a separate Feature studio for the cases when you want to reuse them in the different tabs, this would help a lot to avoid name conflicts and circular references.
  • kevin_o_toole_1kevin_o_toole_1 Onshape Employees, Developers, HDM Posts: 564
    Hi Brooke,

    This is a known shortcoming, and has not been a huge priority to address so far. The cases which hit this are usually trying to place config parameters from multiple part studios in a feature dialog. Is that the case for you?

    If so, I would recommend using a reference parameter in the meantime. I know the UI is not as nicely curated as rolling your own dialog, but it's the best solution right now. We have other improvements coming next year intended to make it easier to curate a set of elements (e.g. Part Studios) intended to be used with a particular dialog.

    If not, what is the problem you're solving with enums from multiple namespaces in a feature? Understanding the need can help us prioritize this issue better!
  • brooke_spreenbrooke_spreen Member, Developers Posts: 115 ✭✭✭
    @konstantin_shiriazdanov , it is indeed a different problem, but the idea to use replaceString() is something to consider in other cases. Thanks! Using a separate Feature Studio for type definitions is precisely the root of my problem here....

    @kevin_o_toole_1, in this case I have a "library" Feature Studio where certain enums are defined. There are two or three features which use these enums in their preconditions. I would like to write a "wrapper" feature, from which any of the three subfeatures can be called. However, if any of the subfeatures reference a different version of the original enum library, I have conflicts in the top feature.

    A quick example- say the enum is "Colors" and the subfeatures are something like "Create colored prism" and "Create colored cylinder", and the top feature is "Create colored solid."

    My current workaround is to encapsulate the main code of each subfeature in a function, and then have the top feature reference the functions rather than the features. This seems to work, and allows for namespacing all imports. It is probably also more efficient? Just took me a bit of thinking to get there!

    Looking forward to the coming improvements. Curating a set of Part Studios that a user can select from the UI would be very helpful for some of our other features.
    Design Engineer | Anerdgy AG
  • kevin_o_toole_1kevin_o_toole_1 Onshape Employees, Developers, HDM Posts: 564
    @brooke_spreen Thank you for the summary! It is helpful to be aware of such cases. Your workaround seems good.

    It also seems like you should be able to get away with importing the desired enums directly from their source, with no namespace, at the deisired version. You would thus use no namespace for the contents of the dialog, and namespace(s) for other conflicting imports. However, without seeing the exact structure I can't say for sure.
  • brooke_spreenbrooke_spreen Member, Developers Posts: 115 ✭✭✭
    No problem! I think I see what you mean. It's good to have options. Thank you!
    Design Engineer | Anerdgy AG
Sign In or Register to comment.