> Nick.. yes you are correct... and thanks for the input.. I kept getting
> convert.touint16 confused with bitconverter.touint16.. sublte distinction
[quoted text clipped - 77 lines]
>> >> > make
>> >> > this work?
Hi Nick,
> But this is much slower than bit shuffling with HostToNetworkOrder or just
> doing it yourself.
I suppose it all depends on what you're doing. If you're working with a
UInt16 in the first place, maybe. I'm not entirely sure that using
HostToNetworkOrder is more efficient otherwise. It may simply be doing what
you're talking about. After all, the bytes *do* have to be reversed. So, in
your case, you're adding the step of converting the bytes to a UInt16 and
then calling a function which converts the UInt16 to an array of bytes,
reverses the order, and then converts the array of bytes back to a number. I
suppose it is possible that it does it all in an unmanaged bitwise way under
the hood, but I doubt it.
In addition, this is fine and dandy if the data you're working with is
confined to 16, 32, or 64-bit numbers. Otherwise, you will have to roll your
own method, as I've done in my library, which works with a large variety of
data types, for the purpose of reading TIFF files.

Signature
HTH,
Kevin Spencer
Microsoft MVP
.Net Developer
Presuming that God is "only an idea" -
Ideas exist.
Therefore, God exists.
> But this is much slower than bit shuffling with HostToNetworkOrder or just
> doing it yourself.
[quoted text clipped - 90 lines]
>>> >> > make
>>> >> > this work?