- Do not allow null string to be passed, raise ArgumentNullException.
- Do not allow string whose ASCII representation is longer than the reserved length, since this currently leads to silent data loss.
- Always write the full binary data length of 2 + reservedLength, since that is what the binary representation of that string is in S7 memory, even if some tail bytes are unused by the current string.
I also suspect that S7WriteMultiple would have chocked on that last bit, but I am not sure. There aren't any tests for writing multiple Dataitems right now.
Adjust tests accordingly. Mostly add some tail bytes where necessary, and assert on exceptions where this is now required.
* Add StringEx.ToByteArray(...)
* Add Serialization.SerializeDataItem(DataItem)
Supports StringEx VarType or offloads to SerializeValue method.
* Use SerializeDataItem in S7WriteMultiple
* Assume string length without header in StringEx.ToByteArray
VarTypeToByteLength already assumed that StringEx declared count for
the number of characters without the header, this now matches that
behavior.
* Add unit tests for StringEx conversions
* Fix incorrect value passed to Encoding.GetBytes
The length must actually be within string limits.
