Swap Delimiters functionality, mixed delimiter scenario

[K3nZo87]

Describe the bug
This one is a bit more tricky than the one I submitted yesterday. The swap delimiters functionality gets confused in a mixed delimiter scenario and does not achieve the intended purpose of converting the delimiters.

After some testing this is what I found to happen:
Scenario 1: Query starts with a semicolon (";") delimiter for an argument and tries to transition to comma (",") delimiter for arguments and dot (".") for numbers
Scenario 2: Query starts with a comma (",") delimiter for a number and tries to transition to comma (",") delimiter for arguments and dot (".") for numbers

This conversion happens:

1. semicolon (";") -> comma (",")
2. comma (",") -> dot (".")
3. dot (".") -> dot (".")

After the swap the query ends up in this state:

1. semicolon (";") delimiters for arguments gets converted to comma (",") delimiters, which is acceptable in a transition to a comma (",") and dot (".") delimiter query
2. comma (",") delimiters for arguments gets converted to dot (".") delimiters, which makes no sense in either transition
3. comma (",") delimiters for numbers gets converted to dot (".") delimiters, which is acceptable in a transition to a comma (",") and dot (".") delimiter query
4. dot (".") delimiters for numbers does not get converted, , which is acceptable in a transition to a comma (",") and dot (".") delimiter query

Scenario 3: Query starts with a comma (",") delimiter for an argument and tries to transition to comma (";") delimiter for arguments and comma (",") delimiter for numbers
Scenario 4: Query starts with a dot (".") delimiter for a number and tries to transition to comma (";") delimiter for arguments and comma (",") delimiter for numbers

This conversion happens:

1. comma (",") -> semicolon (";")
2. semicolon (";") -> semicolon (";")
3. dot (".") -> dot (".")

After the swap the query ends up in this state:

1. comma (",") delimiters for arguments gets converted to semicolon (";") delimiters, which is acceptable in a transition to a semicolon (";") and comma (",") delimiter query
2. semicolon (";") delimiters for arguments does not get converted, which could be acceptable in a transition to a semicolon (";") and comma (",") delimiter query
3. dot (".") delimiters for numbers does not get converted, which could be acceptable in a transition to a semicolon (";") and comma (",") delimiter query
4. comma (",") delimiters for numbers gets converted to semicolon (";") delimiters, which makes no sense in either transition

To Reproduce
Steps to reproduce the behavior:

1. In settings -> defaults separators -> Other is selected
2. In a blank query window type a query with semicolon (";") delimiter
3. Use the Model Metadata to define a measure to reuse some part of that measure's query
4. The definition of that measure that is inserted to the query editor window uses the comma (",") delimiter
5. After using a part of the query from the inserted defined measure, use the swap delimiters functionality with the intend to transition to either semicolon (";") or comma (",") delimiter on the whole query

Expected behavior
The expected behavior would be:
In Scenario 1 and Scenario 2 as described above comma (",") delimiters for arguments to not get converted to dot (".") delimiters.
In Scenario 3 and Scenario 4 as described above comma (",") delimiters for numbers to not get converted to semicolon (";") delimiters.

[dgosbell]

I'm not really sure I understand this issue completely. Is it just when using the Define Measure feature when you already have a partial query using the Other delimiter style? A query with a mixture of delimiter styles would be impossible to reliably swap delimiters on, but I could fix this by running the swap delimiters code before injecting the measure expression into the edit window (since all DAX code is always stored with the US delimiter style inside the model).

If there are scenarios other then using Define Measure can you add some example DAX Queries that exhibit this issue?

[K3nZo87]

With using Define Measure is the only scenario where I have encountered the issue, and I understand that it is somewhat an edge use case. I guess running the swap delimiters code before injecting the measure expression into the edit window would be a solution for that scenario.

What is really interesting to me is that there seems to be a way that the functionality understands the first delimiter style that is in use in the syntax.

For example:
Scenario 3 from my explanation above could be a query like this: IF( [SomeMeasure] = TRUE() , 2,5 ; 2,5 )
and Scenario 4 from my explanation above could be a query like this: IF( [SomeMeasure] = 2.5 ; TRUE() ; 2,5 )
in both queries the functionality seem to understand that it is a comma (",") and dot (".") style the first style it encounters and tries to convert to semicolon (";") and comma (",") style.

This is what it ends up with:
Scenario 3 after conversion: IF( [SomeMeasure] = TRUE() ; 2;5 ; 2;5 )
Scenario 4 after conversion: IF( [SomeMeasure] = 2,5 ; TRUE() ; 2;5 )
where the only failure is inside the numbers.

Scenario 1 from my explanation above could be a query like this: IF( [SomeMeasure] = TRUE() ; 2.5 , 2.5 )
and Scenario 2 from my explanation above could be a query like this: IF( [SomeMeasure] = 2,5 , TRUE() , 2.5 )
in both queries the functionality seem to understand that it is a semicolon (";") and comma (",") style the first style it encounters and tries to convert to comma (",") and dot (".") style.

This is what it ends up with:
Scenario 1 after conversion: IF( [SomeMeasure] = TRUE() , 2.5 . 2.5 )
Scenario 2 after conversion: IF( [SomeMeasure] = 2.5 . TRUE() . 2.5 )
where the only failure is the argument delimiters.

[K3nZo87]

Thank you in advance for the time you dedicate to the issues I post!

[dgosbell]

in both queries the functionality seem to understand that it is a comma (",") and dot (".") style the first style it encounters and tries to convert to semicolon (";") and comma (",") style.

Yes, the swap delimiters functionality is specifically designed in this way so that you can paste in example code from a website and swap it to your delimiter style or you could write some code in your delimiter style then swap the delimiters and send the code to someone that uses the alternate style. As such I make no assumptions about the delimiters and instead scan the expression and attempt to infer the delimiter style from the first usage that is found.

I've put in a fix to make sure that the DEFINE MEASURE feature generates the code with the user specified delimiter style and I think that is the best fix for this issue. That should at least prevent DAX Studio from generating code with mixed delimiters

I don't think there is any reliable way of dealing with mixed delimiter styles other than throwing an error and getting the user to fix this as there are a lot of ambiguous code patterns that could be introduced.