that's really up to you. if i were you, though, i would:
1. sign the NDA and get access to the ROM source code.
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.
moral of this story: sign the NDA and read the ROM source. it will answer
most questions.
----- Original Message -----
From: Ion Popescu <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, June 21, 1999 12:02 PM
Subject: Re: DmFindRecordByID
> I still haven't got the answer to the question I posted.
> I guess the thread got into discussing what is expected
> out of Palm. My question again:-
>
> Should I write a replacement for DmFindRecordByID?
> I have atleast a 1000 lines of code that depends on
> this function - in fact the whole architecture of my program
> depends on this function. If I were to write this function
> myself, should I go sequentially through all records of my
> database? (doing DmRecordInfo on each) Is their any way I
> can do it more efficiently?
> Is there an OS update? if so, which one.
>
> Chris Antos wrote:
> >
> > as with any OS that has multiple versions, no matter how good a job Palm
> > does of making the OS versions compatible, the responsibility still lies
> > with us developers to test and verify our apps against any version of
the OS
> > that we claim our app can run on. it's my own fault if tell my users
that
> > my app works on OS1.0 but i never test it!
> >
> > ----- Original Message -----
> > From: Andreas Linke <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Monday, June 21, 1999 12:13 AM
> > Subject: RE: DmFindRecordByID
> >
> > > >However, if you've particular ones that you think are inappropriately
> > > >fatal, please post 'em here and we can see about fixing them
> > > >as appropriate.
> > >
> > > DmFindRecordByID() is definitely on my list. I use the appinfo block
of
> > > a DB to store record sort information (based on record ID), then use
> > > DmFindRecordByID() to sort the records at program start. I thought
this
> > > would be safe as my program simply ignores entries where
> > > DmFindRecordByID() returned 0.
> > > Some users mysteriously complained about Fatal Errors with invalid
> > > record IDs. Because the errors were fatal (reset), my program would
not
> > > even start.
> > > I only recently learned that older OS versions pad the appinfo block
to
> > > 512 bytes with garbage and DmFindRecordByID will pop up a fatal error
> > > message if the high byte of an ID is not zero.
> > > So in my case, I stumbled over an OS bug (extending the size of the
> > > appinfo block), not a bug in my program. I'm now working around this
by
> > > duplicating part of the code of DmFindRecordByID() in my app.
> > > BTW, I could not have found this problem in a trillion gremlin events
as
> > > it apparently only occurs with certain hotsync/OS combinations.
> > >
> > > ALL the read/check functions (DmGetRecord() with deleted records also
a
> > > good candidate) should return error codes and not popup any message
> > > boxes at all.
> > >
> > > Andreas
> > >
>
