Dave's idea is certainly workable, but there are alternatives.
Databases are best used for long-term storage of data -- such as
from sync to sync. Shorter-term data storage -- such as when
your application (or a particular part of it) is up can be
accomplished in a simpler manner without the overhead of the
database manager.
Thus you could create (what I like to call) a "background structure"
that holds all the information needed about each tooth. You would
load this structure from your database or databases at app start
or form load time, use it for display and editing of data, then
commit you changes back to the database or databases when the
user finalizes them (and then re-load your background structure).
Your gui elements (gadgets, tables, whatever) can then just store
an index into the structure (such as tooth #13). Please don't
forget to dispose of your structure when done.
This is the approach taken by Date Book in its Day View (see the
example code in the SDK and its ApptsH global). It allows for more
flexibility between the gui (view) and data. In your case, Brian,
it would allow you to have the same gui represent a portion of the
mouth (one plate, or even less) dynamically. And it allows you to
use different data representations (multiple databases) without
changing your gui code.
On the other hand, there is cost (complexity, memory) to such an
approach. "Ya pays yur money, ya takes yur chances!"
-bob mckenzie
-----Original Message-----
From: Dave Lippincott [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 16, 2001 6:44 AM
To: Palm Developer Forum
Subject: Re: Basic design issue - Zen Masters, please read...
I'd look into using a DB with 32 records, one for each tooth. Tap a tooth,
load the structure from the DB, make changes then save your tooth
structure/data into the appropriate record when changes are made. You would
then have zen-like data saves plus up to 64k of data per tooth.
----- Original Message -----
From: "Brian Smith" <[EMAIL PROTECTED]>
To: "Palm Developer Forum" <[EMAIL PROTECTED]>
Sent: Wednesday, May 16, 2001 9:21 AM
Subject: Basic design issue - Zen Masters, please read...
> I'm writing a dental-related app, and I need to represent all 32 teeth on
> the main form - the user will tap a tooth to then do something on that
> tooth, and when done, will return to the main form. But there's just no
way
> to put all 32 teeth in that 160 x 160 area - too crowded! But putting 16
> (the upper arch) on one form and 16 (the lower arch) on another form works
> really nicely, and it's no problem to swap back and forth between forms
with
> a button in the same location on each form. So far, so good.
>
> The problem I'm having is in storing the data - each tooth has a fairly
> complex data structure (a struct with several data elements, some of which
> are other structs). Initially, gadgets seemed to be the answer - I can
make
> them look like I want them to look, and each one stores a pointer to data,
> so storing a pointer on each one to the struct makes perfect sense. So
far,
> so good.
>
> But I'm having no luck at all in dealing with the data for each tooth that
> has to be available from all 3 of my forms - the two main forms (upper
arch
> and lower arch), and the 3rd form where all the display and editing is
done
> for all the data on a single tooth. (Tap the tooth on one of the main
forms,
> go to a data edit form for that tooth - when done, save all the editing
and
> return to the main form - very simple, possibly even "Zen" <g>.) I think
> there might be a very common way to deal with gadget data that has to be
> accessible from multiple forms, but I haven't stumbled accross it yet.
>
> Maybe my approach of using the gadgets to store the data is all wrong -
> maybe I need to be reading from and writing to a database every time I
need
> to do anything with the data, because a database would be accessible to me
> at any time during my app, right? I could still use the gadets to
represent
> the teeth, because I can change their appearance to represent the status
of
> each tooth (data entered or updated, tooth missing, adult vs. child tooth,
> etc.). And each time I display the gadgets (switching from upper arch form
> to lower arch form, and switching back and forth between the arch view and
> the single tooth view), I just read the pertinent data from the database
to
> display the tooth appropriately.
>
> I guess I have to use a database anyway, to get the data back and forth
> between the Palm and the desktop, so maybe I'm just as well off using the
> database all the time...
>
> Any advice at this point would be greatly appreciated. I feel like Edison
> when he told the report that he's not discouraged - he now knows over a
> thousand materials that *won't* work for a light bulb filament! I now know
a
> *bunch* of ways that I *can't* design my app!
>
> Thanks,
>
> Brian Smith
>
> --
> For information on using the Palm Developer Forums, or to unsubscribe,
please see http://www.palmos.com/dev/tech/support/forums/
>
--
For information on using the Palm Developer Forums, or to unsubscribe,
please see http://www.palmos.com/dev/tech/support/forums/
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
