VS Extension DataTables - Better handling of numbers in columns

[fredrikeriksson]

Right now it seems that there is only left alignment in data tables which is not very user friendly for columns with numbers.
If looking at the examples here https://cucumber.io/docs/gherkin/reference/#scenario-outline they at least seem to "promote" this.
I can't find anything about alignment in the extension code, maybe I'm missing something?

A workaround I have is to prefix with zeros but that is not as elegant as I would like it.

Another thing to take into consideration is right-to-left languages.

[fredrikeriksson]

One more input in the matter is that I just noticed that the HTML formatter seems to align as expected without prefixing zeros.
So I guess this is just limited to the formatter in the extension, which makes this less of an issue when #233 is completed.

[clrudolphi]

Yes, the VisualStudio extension currently left aligns.
To flesh out this idea a bit further, what types of table cell content should be right-aligned?

• strings of digits only
• strings that contain digits and culture-specific separators (such as comma and period)
• strings that contain a prefix or suffix currency symbol? Should that be any recognized currency symbol or the symbol belonging to the current culture?
• numbers in scientific notation? (1.234E12)

Any others?

I would be inclined to test for the presence of any alpha character (perhaps other than e/E) or any non-currency non-alphanumeric character (other than common separators), and if found treat it as not a number (left-aligned), otherwise right-aligned.

[fredrikeriksson]

Sounds good to me! 😊

[clrudolphi]

The euro currency character is troubling and I'm not sure how to address this.
In my test, I used Visual Studio and our current release VS Reqnroll Extension to create a new Reqnroll Project. I upgraded to our latest release version Reqnroll. I edited the default feature file to include the table of test values (including the currency symbol). I saved that and compiled.

After reviewing everything, the trail finally leads to the fact that the feature file is (by default?) saved to disk encoded as Windows-1251 which uses x80 as a single byte representation of the euro currency symbol. When this feature file is read by the Gherkin parser, it seems to be assuming UTF-8 and as a result, the illegal x80 is replaced with the unicode ReplacementCharacter \uFFFD.

There is nothing wrong per se with the way in which the Formatter code is handling this.
As evidence of that, since this sample feature file is using these values as a Scenario Example, the MsTest row test attributes also include the \uFFFD replacement character in place of the euro currency symbol.

If you can point to a quick fix, I'll look into it. Otherwise, I'll post a separate Issue/Bug. How have other users not run in to this?

[gasparnagy]

If you can point to a quick fix, I'll look into it. Otherwise, I'll post a separate Issue/Bug. How have other users not run in to this?

Let's make a separate issue for that. I remember having something similar, but I need to think about what the solution was.

[clrudolphi]

From the Visual Studio documentation:

Starting in Visual Studio 2022 version 17.13 Preview 1, you can set the default encoding for saving files.

To set the default, choose Tools > Options > Environment, Documents. Next, select Save files with the following encoding, and then select the encoding you want as the default.

I did this and then resaved the feature file that was causing problems and the code-behind now had the correct value in the DataRowAttribute:
[Microsoft.VisualStudio.TestTools.UnitTesting.DataRowAttribute("€", "", null)]

Is there anything we should change in the Extension to set the sample feature-file's encoding?

[304NotModified]

@clrudolphi please create a new issue for that :)
I also think this underlying issue is the Encoding.Default here:

Reqnroll/Tests/TestProjectGenerator/Reqnroll.TestProjectGenerator/Factories/ProjectFileFactory.cs

Line 10 in d676a10

=> FromStream(source, projFileName, projFileAction, Encoding.Default);

Related info https://learn.microsoft.com/en-us/dotnet/fundamentals/runtime-libraries/system-text-encoding-default