"Stephen Best" <[EMAIL PROTECTED]> wrote in message
news:40430@palm-dev-forum...
> > And of course that would be an incompatible change between OS
versions...
>
> Sounds to me like something that should have been fixed long ago!
In general, you have to weigh the cost of making incompatible changes
against the benefit of an improved API. In this case, it doesn't seem like
it's worth it. If DmResizeRecord set the busy bit, callers would have to
subsequently call DmReleaseRecord to clear it. Apps that resize records
smaller might not need to write to the record, so they might not bother. The
result would be records getting left busy, causing trouble down the road.
It's not clear to me that having DmResizeRecord set the busy bit is an
improvement. After all, why not make DmWrite set the busy bit? John's idea
of passing it a (writable) handle is a good one, but it needs the record
number as well so it can update the handle if necessary.
> > It looks like thinking of DmResizeRecord as modifying an *existing*
> > writable handle, rather than returning a new one, is the right way to
go.
>
> Huh? Let's say I do a DmResizeRecord by itself, either to truncate or
> elongate a record. The *existing* record has changed and should, by
rights,
> have the dirty bit set. Why do I then have to futz around with
> DmRecordInfo/DmSetRecordInfo when there's already a nifty function that
does
> exactly this.
The existing record should _have_ had the dirty bit set before you modified
it (by resizing it). I didn't recommend using DmSetRecordInfo. I'd use
DmGetRecord, as John described. The busy and dirty bits are stored in the
record header, so the *existing* record is the same as the new (post-resize)
record, even though it might have a new handle.
> And sure in my original sequence I can do a DmResizeRecord/DmGetRecord
combo
> but isn't this just a waste of cycles?
Any protection mechanism, is, by definition, a waste of cycles. But it buys
safety, and thereby data integrity. I'd do the DmGetRecord before the
DmResizeRecord, as John described.
> The jury is still out on DmAttachRecord ... :-).
The new record is marked dirty, but not busy. Write protection isn't really
an issue since you presumably wrote to the nascent record before you
attached it.
--
Danny Epstein
OS Engineer, Palm Inc.
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
