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.
FeatureScript question. allowing variable names with/without spaces
jelte_steur_info
Member Posts: 638 PRO
In Onshape's native variable features, there's a verifyVariableName feature that a.o. checks if variable names already exist as a different type of variable (like query ~).
moreover it will throw an error if it contains spaces, which forces us tot type with dashes or underscores etc (camel, snake, Pascal or kebab or something made up).
I programmed a setQueryVariable function into another function the other day and found that at least query variables work perfectly well with spaces in the names.
Why is the native Onshape feature this strict? (making typing a name less intuitive).
In what circumstances could a custom feature cause issues when I'm not as strict?
Best Answer
-
Konst_Sh
Member Posts: 124 PRO
Using spaces in identifiers would screw up expression parsing, you can make multiword descriptions for variables, but keep the name short enough to let it be conviniently used in expressions
1
Answers
Using spaces in identifiers would screw up expression parsing, you can make multiword descriptions for variables, but keep the name short enough to let it be conviniently used in expressions
@Konst_Sh :
Got it, for regular variables that makes sense.
how about Query variables? those can't be used in expressions.
I would say query variables should not be different in that sense, even if some function s allow spaces in their names. In the future we can make a query expression feature or for example an expression input type for QV+ feature, so it doesn't make sense to go against this rule just because it has specific data type
I agree.