in datamgr.h, SortRecordInfoType has "Byte uniqueID[3]". so, it's set in
stone. you can't change that without busting people.
sure you could add an extra byte and get away with it since the Palm is
LittleEndian, but you'd be changing the sizeof(SortRecordInfoType), which
will break everyone who uses SortRecordInfoType. SortRecordInfoType doesn't
have any kind of cbSize member or cVersion member at the beginning, so the
OS has no way to detect/specify what "version" of the SortRecordInfoType is
being used.
----- Original Message -----
From: David Fedor <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, June 23, 1999 11:12 AM
Subject: Re: DmFindRecordByID
> >2. look up DmFindRecordById in datamgr.c, and discover that the only
thing
> >it will complain about is if the high bits are set in the unique id.
> >3. then i'd accept that if the high bits are set, it really is a bogus
> >unique id.
> >4. i'd decide the problem doesn't lie with DmFindRecordById at all.
> >5. finally, i would simply mask the unique id with 0x00ffffff before
calling
> >DmFindRecordById.
>
> Be careful - I don't think there's any guarantee that record ids are
> limited to that range. It'd be a bummer if we couldn't expand the OS
> because too many folks were doing this masking.
>
>
> >moral of this story: sign the NDA and read the ROM source. it will
answer
> >most questions.
>
> It certainly gives you tons of information. But what it currently does
> isn't any guarantee about what it'll do in the future - one of the reasons
> people were worried about releasing the OS source is that it is too easy
> for folks like you to make assumptions like this, which can make serious
> compatibility problems or constraints on improving the OS.
>
> Please be wise in what you do as a result of poking around in the
sources...
>
> -David Fedor
> Palm Developer Support
>
>
>
