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.
Options
Enum dereferencing?
S1mon
Member Posts: 2,359 PRO
I've been working on configuring some standard part color choices using a custom featurescript. As some of these options have been changing, I'm starting to wonder if it would make sense to have an internal code for the enum which is some random numbers/letters, and have all the human readable stuff in the enum const definition. That way parts which use the custom feature could continue to update without needing to redo configs if the color name changes slightly or if I add or move a color choice.
What I have is conceptually like this code snippet:
--------------------------------
export enum MyColorNames
{
annotation { "Name" : "01 Red"
RED,
annotation { "Name" : "02 Blue"
BLUE,
annotation { "Name" : "03 Green"
GREEN,
}
export const MyColors = {
"RED" : { "variant" : "-01", "color" : color(1, 0, 0), "colorName" : "Red" },
"GREEN" : { "variant" : "-02", "color" : color(0, 1, 0), "colorName" : "Green" },
"BLUE" : { "variant" : "-03", "color" : color(0, 0, 1), "colorName" : "Blue" },
};
--------------------------------
I'm considering doing something like this with random-ish codes:
--------------------------------
export enum MyColorNames
{
annotation { "Name" : "01 Red"
A12,
annotation { "Name" : "02 Blue"
B34,
annotation { "Name" : "03 Green"
C73,
}
export const MyColors = {
"A12" : { "variant" : "-01", "color" : color(1, 0, 0), "colorName" : "Red" },
"B34" : { "variant" : "-02", "color" : color(0, 1, 0), "colorName" : "Green" },
"C73" : { "variant" : "-03", "color" : color(0, 0, 1), "colorName" : "Blue" },
};
--------------------------------
The idea being that I could tweak the variant number, the color values, the names, or add/insert/delete color choices without screwing up part configurations which use this feature script too much. Right now, if I change the enums in the MyColorNames, then any config which uses that choice is undefined or defaults to the first choice.
Is this sort of dereferencing used much with enums?
What I have is conceptually like this code snippet:
--------------------------------
export enum MyColorNames
{
annotation { "Name" : "01 Red"
RED,
annotation { "Name" : "02 Blue"
BLUE,
annotation { "Name" : "03 Green"
GREEN,
}
export const MyColors = {
"RED" : { "variant" : "-01", "color" : color(1, 0, 0), "colorName" : "Red" },
"GREEN" : { "variant" : "-02", "color" : color(0, 1, 0), "colorName" : "Green" },
"BLUE" : { "variant" : "-03", "color" : color(0, 0, 1), "colorName" : "Blue" },
};
--------------------------------
I'm considering doing something like this with random-ish codes:
--------------------------------
export enum MyColorNames
{
annotation { "Name" : "01 Red"
A12,
annotation { "Name" : "02 Blue"
B34,
annotation { "Name" : "03 Green"
C73,
}
export const MyColors = {
"A12" : { "variant" : "-01", "color" : color(1, 0, 0), "colorName" : "Red" },
"B34" : { "variant" : "-02", "color" : color(0, 1, 0), "colorName" : "Green" },
"C73" : { "variant" : "-03", "color" : color(0, 0, 1), "colorName" : "Blue" },
};
--------------------------------
The idea being that I could tweak the variant number, the color values, the names, or add/insert/delete color choices without screwing up part configurations which use this feature script too much. Right now, if I change the enums in the MyColorNames, then any config which uses that choice is undefined or defaults to the first choice.
Is this sort of dereferencing used much with enums?
0
Comments
Website: ovyl.io
Yes. That's one of the issues, but the main thing I'm trying to avoid is having parts (which use the custom feature) and assemblies which have been configured loosing their configurations because the enum is gone. The whole point is to have one document (the custom feature) to tweak the colors, names and codes.
Unfortunately I still have to enter or copy/paste the names of the configs, but overall this is saving some time and avoiding having slightly different colors or mismatched variant codes.
I'm assuming that there are other examples where configurations are being used to drive custom features and you might want to tweak the nomenclature for stylistic reasons or update something without having to fix a bunch of parts.