On Tue, May 07, 2002 at 04:50:05PM +1200, Chris Tutty wrote:
> From: "Danny Epstein" <[EMAIL PROTECTED]>
>> http://www.escribe.com/computing/pcpqa/m47007.html
>
> There are a million messages explaining how to set the tver 1 and
> 1000 resources but I can't find any information on how to change
> the PalmRez version *programmatically*.
I tend to call it the database header version number (short for "version
number within the database header"), because it lives in the database
header. Not everyone uses PalmRez.
"Programmatically" usually means on Palm OS via Palm OS APIs; because
this version number is in the database header, it's not too surprising
to learn that it can be changed via DmSetDatabaseInfo.
But it seems you want to do it at build time. This is easy to do with
prc-tools: just use "build-prc ... --version-number N". You can also do
it after the fact by munging an already created .prc file with tools
like par -- and this might be a viable approach for you. I was hoping
to see it in Constructor's μMWC editor pseudo-panel alongside the
other things -- database name, etc -- that go into the database header,
but alas no.
> Alternatively, is it a problem if the prc database version number
> (set using the PalmRez settings) panel is the same for all prc's?
I don't believe so. If you look at all the .prcs on your device, I
think you'll find that practically all of them just have the header
version number set to 1 [1]. If this is a problem, it can't be a very
serious one, because everybody's survived so far :-).
Danny's post from last year (URL above) noted that it's only really used
to choose between different databases with the same type & creator ID by
DmGetNextDatabaseByTypeCreator, and by the Launcher as a last-chance-if-
you-don't-have-a-tver version number.
Let's suppose you have an app, and you produce a new version of it: same
database name (of course, right?! :-)), updated tver resource, but the
same database header version number.
The database header version number will only make a difference if there
are two instances of your app on a device at the same time that need to
be distinguished between. Because the database name is a unique key
within a heap (or store or whatever it's called), this will only happen
if the old one is in ROM and the new one is in RAM and is supposed to
override the old one. If you care about situations in which your app
might be in ROM, you might want to update your database header version
number, although the RAM one is supposed to win anyway by virtue of
being in RAM.
When a new database is being installed, either by HotSync or beaming, I
believe it'll overwrite the existing one regardless of version numbers,
just by virtue of being newly arrived. So the database header version
numbers probably don't matter too much in this case either.
Another case is having the old version of your app in main memory and
the updated one on an expansion card. With the current Launcher, these
are separate arenas in the UI, so the two don't conflict, so again the
database header version numbers probably don't matter. (What happens
when you run the one on the card and it potentially confuses the old one
in main memory is a separate story, of course.) It might be different
with cards and other (future) Launchers -- I wonder if this is a reason
for worrying about database header version numbers?
But basically for an app you probably don't have to worry about it too
much. I think.
John
[1] or 0, as I noted in my followup to Danny's post linked to above
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
