Ok, I'm happy to see that I'm not crazy (for thinking that the error was a
change), and very happy to read that it's an assert that won't be in release
code.
But the question remains, what is the "proper" way to address the situation?
Is the extraneous call to DmGetRecord the best/most efficient way? Assuming
that I know that I need to resize the record, and that I don't already have
a writable handle, is there a significant difference between:
VoidHand nameRecHan = DmGetRecord(gNameDB, recIdx);
nameRecHan = DmResizeRecord( gNameDB, recIdx, . . .
and this:
VoidHand nameRecHan = DmResizeRecord(gNameDB, recIdx, . . .
nameRecHan = DmGetRecord(gNameDB, recIdx);
If the resizing moves the record, the subsequent get should get the new
handle, right? So the two cases should be equivalent. Is one to be preferred
for some reason, or is it just a wash?
In one of the previous threads on this topic (thanks, Danny, for the
pointers to them), Jason Dawes included a code snippet in which he did a
get, then a release before the resize. It seems to me that the intervening
release is unnecessary (not to mention self-defeating for overcoming the
assert in question). Doesn't DmReleaseRecord basically just unset the busy
bit and optionally set the dirty bit?
I'm hoping that Danny Epstein is still reading and can quickly address these
questions. Thanks in advance.
--Jim Preston
"Danny Epstein" <[EMAIL PROTECTED]> wrote in message
news:42374@palm-dev-forum...
>
> See the following threads in the archives:
>
http://www.escribe.com/computing/pcpqa/index.html?by=OneThread&t=OS%204.0dr4
> %20-%20DataMgr.c%2C%20Line%3A6915%2C%20Record%20isn%27t%20busy
>
http://www.escribe.com/computing/pcpqa/index.html?by=OneThread&t=DmGetRecord
> %20vs%20DmResizeRecord%20handle%20%28again%29
>
> All this trouble over one little assert. That'll teach me... :)
> --
> Danny Epstein
> OS Engineer, Palm Inc.
>
>
> "James Preston" <[EMAIL PROTECTED]> wrote in message
> news:42372@palm-dev-forum...
> > I just tried testing my application with the 4.0 ROMs, and I've hit an
> oddity
> > that's either a bug in 4.0 or my misunderstanding. I'm hoping someone
can
> > clue me in.
> >
> > Here's the part of my application that's in question:
> >
> > VoidHand nameRecHan = DmResizeRecord(gNameDB, recIdx, sizeof(NameInDB) +
> StrLen(newName));
> > if (nameRecHan) {
> > NameInDBPtr nameRecPtr = MemHandleLock(nameRecHan);
> > DmStrCopy(nameRecPtr, offsetof(NameInDB, projectName), newName);
> > MemPtrUnlock(nameRecPtr);
> > DmReleaseRecord(gNameDB, recIdx, true);
> > }
> >
> > This worked fine in 3.5, but with 4.0, the emulator throws an error at
the
> > call to DmReleaseRecord that the record is not busy. I've scoured the
API
> > docs, and it does not explicitly say that DmResizeRecord sets the busy
> bit,
> > but I had thought that that was the case. Have I been mistaken all this
> time?
> > Given that DmResizeRecord returns a handle to the new record, it doesn't
> > really make sense to me that it wouldn't mark it busy. I mean, I would
> think
> > that the vast majority of the time, when you resize a record you're
going
> to
> > want to write into it next.
> >
> > The only way I've found to fix the above is to add a call to DmGetRecord
> > before the resize, in order to force the busy bit to be set, like this:
> >
> > VoidHand nameRecHan = DmGetRecord(gNameDB, recIdx);
> > nameRecHan = DmResizeRecord(gNameDB, recIdx, sizeof(NameInDB) +
> StrLen(newName));
> > if (nameRecHan) {
> > NameInDBPtr nameRecPtr = MemHandleLock(nameRecHan);
> > DmStrCopy(nameRecPtr, offsetof(NameInDB, projectName), newName);
> > MemPtrUnlock(nameRecPtr);
> > DmReleaseRecord(gNameDB, recIdx, true);
> > }
> >
> > But that seems like a wasted call.
> >
> > So is DmResizeRecord supposed to set the busy bit, and this is really a
> bug
> > in 4.0, or have I been writing buggy code all this time and just got
lucky
> > up until now? And if that's the case, is there a better way to do this
> than
> > to make that extraneous call to DmGetRecord?
> >
> > Thanks,
> > --Jim Preston
> >
> >
> >
> >
>
>
>
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
