>Hi George,
>
>slightly off topic, but since you answered to the "RtlMoveMemory",
>perhaps you can straighten me out...(at the moment I am not thinking to clearly, to much midnight oil <g>)
>
>Sometimes I have to convert WINAPI 32Bit unsigned integers (LONG) to vfp numerics,
>and this conversion should be as fast as possible for use in timing routines:
>the "normal" runtime characteristics shouldn't be disturbed by timing routines.
>
>AFAIR I tried doing that with RtlMoveMemory once, but ran into trouble somewhere around 2**31,
>which meant for me some problem with the bit defining the sign of the number, or translation problems with INTEGER/LONG in the declare line.
>
>At the moment I cannot find the code for that, but since I wanted to follow up on this approach and
>compare this way of operating to my best vfp-based solutions, perhaps I'll try to recreate it.
>
>First, is there anything conceptually wrong with such an approach ?
>I thought this should be something like typecasting in vfp: interpret the bytes from a certain memory location as a specific type.
>I seem to remember a difference in the range of integers for table fields from vfp to sql server,
>but that shouldn't be a factor here AFAIK.
>
>Any thoughts ?
>
>Regards,
>
thomas,

It may be a problem due to the fact that VFP treats all integers as signed. There are several copies of my string to integer class in the download section. The only reason I mention it is that it allows a workaround to the problem of signed integers. For example, see Obj2Bmp or Windows Time. AIRC, both use the class that houses StringToInteger.