Consider that the ordinal value of any specific character is given by the position of the character in the ASCII table, which is why I posted a link to it. Seems the OP didn't even notice it. Instead, we ended up with a senseless debate about ordinal values of characters versus strings. smh.
According to the ASCII table, the ordinal (decimal) value of the character '0' (zero) is given as: Ord('0') = 48.
You can see this if you display the result of: Format( 'Ord(''0'') = %d', [Ord('0')] ); since Ord() returns an integer value, and this displays it as a decimal number.
The ordinal value of the character '9' is: Ord('9') = 57.
However, while the next Hex digit is 'A' (or 'a'), the character following '9' is Chr(58) which = ':' (colon).
In practice, Hex digits are not case sensitive, so the hex value of 'a' is the same as the hex value of 'A', both of which correspond to the decimal value of 10 (ten).
However, Ord('A') = 65 while Ord('a') = 97.
Ord('9') is 57 while Ord('A') = 65. So the ordinal values of the 16 ASCII characters that are used to represent Hex digits is not a continuous array of 16 values from:
it goes from Ord('0') = 48 to Ord('F') = 70.
The range between those two ends is 22, not 16.
And if you use lower-case 'a'..'f' then the difference is Ord('a') - Ord('A'), or the entire range defined as [48 .. 102], again far more than 16 elements.
The ordinal value of a string is undefined. So Ord( '0000' ) is an error, neither zero nor 48. Never mind that these are actually BINARY representations (0 or 1), and to the compiler they're just 4-character strings.
You have to parse the digits in each position of a Hex number the same way as you do decimal numbers, except you need to multiply each successive position by a power of 16 rather than 10.
Simple arrays that serve as lookup tables work for decimal numbers only because the digits zero through nine are contiguous in the ASCII table, and you can simply subtract Ord('0') from the ordinal value of the number you're dealing with to get its actual decimal value. The range of hex characters is NOT contiguous with the ten decimal numbers, and in fact is different based on whether the given hex digit is in upper- or lower-case. So you cannot use simple lookup tables to do this thinking that a range of 16 characters is going to work in all cases. It will work for the ten decimal characters, but NONE of the hex characters. And certainly not for strings expressed as 4-character BINARY (0 + 1) versions of hex digits!