>>Both are 'polynomal PKZip CRC32 compliant'
>>
>>Whether you return an Integer (which can be < 0) or a UInteger (always >= 0) , does not matter. It's the bit pattern that matters, ie
>>
>>

>>0xFFFFFFFF
>>
>>is -1 if it is an Integer
>>is  4,294,967,295 if it is a UInteger
>>

>>
>>So,
>>
>>

>> dim xx as Integer = &HFFFFFFFF  ' -1
>>
>>or
>>dim xx as UInteger = &HFFFFFFFFUI ' 4,294,967,295 
>>

>>
>>Both bit structures are equal
>
>Well, a code I am converting right now needs access to my CRC32 class to collect the CRC32 of a file. However, this has to be compared with a CRC32 value which has been stored long time ago as part of the file name. So, using my class we wouldn't be able to compare and find a match. So, at this point, we are looking at building a secondary CRC32VFP(), which would be the one compliant with the old code so we can use it in one specific location where we would have to lookup for a specific string in the file name in regards to that.
>
>Unless you have a suggestion in the .NET class I am using to be able to support that.


(1) CRC32VFP()
Is the part of the filename a val(crc32) from vfp? Then it will be unsigned. So, have your .net class return a UInteger and interprete the part of the filename as UInteger

That way, you can compare UInteger and UInteger types