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/
