#343 Endianness is nowhere considered => parser warning should be improved

[Maettu]

Maybe no longer required, since parser now parses contiguous sequences of any length.
If still required, add some test cases with a different endianness.

[Maettu]

Still needed, fixed.

[Maettu]

YAT versions 1.99.70 and 1.99.80 used to take the endianness into account when encoding and decoding multi-byte encoded characters. However, it was always done, but of course e.g. UTF-8 is independent on endianness. The endianness would only have to be applied single multi-byte values, not multi-byte values split into multiple fragments. However, a .NET 'Encoding' object does not tell whether the encoding is potentially endianness capable or not. Thus, it was decided to again remove the character encoding endianness awareness.

Info message added to 'AdvancedTerminalSettings':
The endianness is currently fixed to 'Big-Endian (Network, Motorola)'. It was used by former versions of YAT but is currently not used anymore. Still, the setting is kept for future enhancements as documented in bug #343.

[Maettu]

Inputs and considerations:

• Current implemenation allows e.g. \h(010203040A0F) to easily send data from e.g. a .hex file.
• Same for \b(11000011)
• Same for \o and \d but isn't really intuitive:
  • \d(100) is OK
  • \d(1000) results in \d(100 0)
    • => not intuitive at all...
  • But implemented like this for consistency with \h and \b
• Alternatively, \d and \o could be implemented intuitively and take the Endianness into account. However:
  • There is no built in type to deal with super-long values like \d(10000000000000000000).
  • For big-endian, how many zeros shall be prepended?
    • => would require another setting like Byte Width = 4/8/...
  • But again, does different behaviour for \d and \o really make sense?
• Yet alternatively, \d and \o values above 0xFF could result in a parser error.

Depending on input and requests from others, Endianness will again be needed or can be removed.

[Maettu]

Opinion SSt: Can be removed.

[Maettu]

Already started completely removing from code, but somehow hesitated because endianness might be required to properly encode Unicode notation "\U+20AC" or "\U(20AC)". But that's neither the case, as the parser rather uses the configured encoding.

Thus, endianness completely removed from code. Still open:

• Parser warning on e.g. \d(1000) behavior described further above.

[Maettu]

Endianess restored from SVN revision #4093 as it is potentially needed for appending CRC.