Namespaced enums in feature UI's

brooke_spreen

Can anyone shed some light on why enums cannot be namespaced when used in feature UI's?

konstantin_shiriazdanov

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_1

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_spreen

@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.

kevin_o_toole_1

@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_spreen

No problem! I think I see what you mean. It's good to have options. Thank you!