To quote or not to quote, that is the confusion

Question

I want to assign "Redmond" to a string variable. In the Expression Editor, I have to enter "Redmond". If I leave off the quotes, the editor thinks Redmond is an expression.
Now I want to use a Switch to evaluate the value of the string variable. If I enter "Redmond" as the Case, the workflow thinks I entered ""Redmond"" and the Case never occurs. I have to enter Redmond without the quotes.

Is it just me, or is that confusing?

Robert

Answer 1

I vote it's confusing.

bob

Answer 2

Thanks for your feedback. We will look into this.

Answer 3

Hi, this isn't the first time that we've heard that it is a problem that you have to wrap your strings in quotes in certain expressions (eg, in a WriteLine) and not in others. The root cause of the problem is that arguments are bound to expressions and properties generally are not. 

For such a simple thing, it's surprisingly hard to solve. String properties are not typically quote delimited, if we change that behaviour we would lose parity with other editors (eg, WPF) and the property grid experience would be rather surprising. For expressions, automatically wrapping in a string for arguments of type string when an expression is invalid is rather ugly, you'd have to rewrite a bunch of expressions when assemblies are added/removed, variables are added/deleted, etc and it turns into a bug farm. 

We're kind of stuck with this clunky experience. To help users figure out where a VB expression is required, we made the default hint text "Enter a VB expression" for most expression text boxes. Are there other things we can do in the UI to help you figure out where quotes are required and where they are not required?

Thanks

Answer 4

Would a warning tooltip of some kind be possible if it seems the user may be making this mistake?

Answer 5

Making sure it is well documented would be a good place to start. The topic for the Switch activity should be clear on it and could include a Note explaining why.

Robert