HexToString functionality

[cristianbuse]

I am a bit confused about the purpose of having separators allowed in HexToString.

For example HexToString("0xA A A A A") seems to be turned into 0aa0aa0a and gets converted to string.
However, HexToString("0xA A A") seems to be turned into 0aa0a and raises a 'length is not even' error although both this and the above example have an odd number of A characters.

Questions:

1. Is a separator supposed to be the value 0 (zero) if and only if there is a single following character followed by another separator?
2. If answer to question 1 is True, then why isn't 0xA A A A A turned into 0a0a0a0a0a?
3. Why does the hex need to be even? In VBA something like &H0A0B gets turned into &HA0B by the IDE. Should this function allow a hex like 0xA0B and view it as 0x0A0B?. Currently, HexToString("0xA0B") is seen as invalid but HexToString("0xA 0B") is seen as 0a0b.
4. Is 0x allowed everywhere? Currently it gets replaced regardless of position like in HexToString("0xA 0xB") which is also seen as 0a0b. Should it be allowed only as first 2 characters on the left?
5. Should &H be allowed instead of 0x?

Thanks!

[guwidoe]

1. True.

2. Because of a bug.

3. Because every two characters comprise one byte. Implementing logic to add a 0 at the front whenever the length is not even could, and probably would, change every single byte of the string, so the function expects a leading 0 to exist if that is desired. I think doing that implicitly could lead to hard-to-debug errors. The IDE converts as you describe, but the function accepts strings, not IDE hex-literals. If a hex literal is copy pasted from the IDE to a string which is then passed to the function, the 0 must be added manually if required.

4. Yes that is deliberate. That could be changed to only be allowed on the left but I don't see the benefit of that. The function is meant to be relatively flexible in its input format.

5. Yes, I don't see a reason why not.

I have already fixed the issue raised in 2 and implemented the feature requested in 5. Will push soon :)

[cristianbuse]

Because every two characters comprise one byte. Implementing logic to add a 0 at the front whenever the length is not even could, and probably would, change every single byte of the string, so the function expects a leading 0 to exist if that is desired. I think doing that implicitly could lead to hard-to-debug errors

I agree. I think this should apply to all the delimited parts as well. Meaning no separators should be allowed. It should also be the user's responsability to make sure each part has full bytes and so separators should be removed entirely. This would also mean that 0x and &H should only be allowed once at position 1 or can be missing.

The benefits would include:

1. No need for RegEx
2. No complex logic
3. Standardized input

[guwidoe]

I agree, maybe ditching delimiters altogether would be more desirable. I implemented it because I wanted to at least match the functionality of this (far inferior) solution.

So just to clarify you are in favor of not allowing separators, not even single spaces? If True, I'll adapt it accordingly.

[cristianbuse]

Yes, definitely in favour of no separators. It should be the user's responsibility to concatenate parts. Maybe a separate method for joining parts if ever needed.

[cristianbuse]

Unrelated with the functionality discussion above, we can implement the same performance approach like in #3

[cristianbuse]

Dealt with in 6a4719e