--On 14 July 2001 13:00 -0700 Jim Schram <[EMAIL PROTECTED]> wrote:
> At 12:46 PM +0100 2001/07/14, Igor Mozolevsky wrote:
>> However, that is EXACTLY what the SDK reference implied... If you read
>> it, you'll see for your self...
>
> The SDK references says:
>
> ---
> Move a range of memory to another range.
> ...
> Handles overlapping ranges.
> For operations where the destination is in a data heap, see DmSet,
> DmWrite, and related functions. ---
>
> Nowhere does it imply the source memory area is modified.
>
> Your misconception is based on the concept of moving physical objects
> from one location in space to another, which does in fact change the
> characteristics of the source location. I agree with your assertion that
> a better name for the routine would be MemCopy not MemMove. But rather
> than beat a dead horse... just #define MemCopy(d,s,c) MemMove(d,s,c)
No, actually, my misconception is based on the fact that in every single
english dictionary, that I managed to look at, verb 'move' meant take from
one place to another. For all I knew, it could deallocate the source
memory, just what 'move' means... This is just one of the 'inventions' of
the SDK...
The second, a more significant one, is the mismatch of two interdependent
functions, FldGetScrollValues and SclSetScrollBar... The former one takes a
pointer to an _unsigned_ 16 bit integer, and the latter one takes
_*signed*_ 16 bit integer values... Is there a _good_ reason for that or is
the reason:- 'why not?'?..
IM :-)
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
