On 7/23/05, will rogers <[EMAIL PROTECTED]> wrote:
>
> Hi Layne,
>
> Since no one else seems to be helping out I'll give you my two cents.
>
> >
> >1) My first question is that at the moment, I am using a temporary
> >Field to display text for debugging purposes.
>
> Jürgen Wind's suggestion about "HostTrace" calls and Reporter is good.
> I've used them for solving some very tricky problems.
>
> We also use terribly simple functions like the
> ones below to pop up a dialog box holding
> "printf-like" information. Very simple, but
> effective. You do have to hit the OK button (and
> define the resource for the dialog). Alos, if
> your code is timing sensitive, you may have to
> result to something else or be very quick on the
> OK button.
>
>
> /***********************************************************************/
> /* Debug Functions */
> /***********************************************************************/
> void
> DbgAlert (const Char *formatStr, ...)
> {
> va_list args;
> Char text[128];
>
> va_start (args, formatStr);
> StrVPrintF (text, formatStr, args);
> FrmCustomAlert (DbgDlgAlert, text, "", "");
> va_end (args);
> }
I don't think I would have been able to come up with that myself, but
now that you show it, it is a very obvious solution. Perhaps the
biggest hurdle for me is finding the standard C equivalents in the
PalmOS SDK. I would have never thought to look for StrVPrintF() as
the PalmOS version of vprintf(). Thanks for the suggestion. I'll
have to use it when I need to debug my code.
>
> char *
> FmtError (Err err)
> {
> char text[64];
> return (SysErrString (err, text, 64));
> }
Again, this looks like a handy debugging function. I'll need to look
at the PalmOS reference to check what SysErrString() returns. It
looks like it might return a pointer to the array passed in. Is that
correct? If so, there may be some memory issues here since the array
is allocated on the stack as a local variable. At least, that's how
it would work with C on a desktop system. I doubt that the Palm does
anything different when it comes to local variables. Anyway, I'll
look into it further.
> /***********************************************************************/
> /* End Debug Functions */
> /***********************************************************************/
>
> Examples:
>
> 1) A simple use like:
>
> DbgAlert("FwGetLog:");
>
> will just pop up the dialog to tell you where you are in code flow.
>
>
> 2) You can get more complex if you like:
>
> DbgAlert("FwIsInterfaceUp:\n error: %x\n, driver %x\n, interface: %x",
> error, driverIsUp, interfaceIsUp);
>
> The newlines (\n) can make it more readable.
>
>
> 3) The "FmtError()" function takes and error code and returns a string.
> Really helpful for debugging system calls:
>
> error = SysLibFind(.....)
>
> DbgAlert("SysLibFind error: %s", FmtError(error));
>
> This can save a lot of time and frustration looking up error codes.
>
>
> >
> >2) As I said earlier, I'm using a Table control on my main form. I
> >know that I need to use a database to make the data persistent once
> >the user enters anything. What common practices are used when reading
> >and writing with a database? For example, I see at least two options:
> >a) declare a global DmOpenRef and keep the database open during the
> >whole lifetime of my app or b) have a local DmOpenRef in each of the
> >functions that access the database and then open and close the
> >database each time. I think I prefer the later for several reasons.
> >First, I dislike global variables and avoid them when I can. Second,
> >I will only use resources (memory, i/o connections, etc.) as
> >necessary. Is this the common approach?
>
> Either one is fine. I am like you, I like to avoid globals.
> (probably comes from my past wrestling with large old complex FORTRAN
> programs)
>
> The good news is that the overhead on a memory-based system like this
> is trivial in comparison to a disk-based system.
> Opening a DB, reading and writing, and closing
> can all be done in a local context with no
> appreciable delay.
>
> I wrote some test programs to open and close a DB
> 10,000 times and divided the results by 10,000.
> The results of a open/close sequence was
> negligible. That being said, the newer NVRAM
> devices do have some issues in terms of speed and
> caching. Look in this group and the
> PalmSource/PalmOne sites (whitepapers) for more
> info.
>
> >
> >3) If I use approach (b) that I described above, then what is a
> >graceful way to deal with errors from the database? For example, I
> >have a MainFormInit() function that is called when the main form's
> >event handler recieves a frmOpenEvent. The primary purpose of this
> >MainFormInit() is to initialize the Table control in my app, which
> >means I need to load some data from the database. At the moment, I
> >have this:
> >
> > DmOpenRef dbHandle = DmOpenDatabaseByTypeCreator('DATA', CREATOR,
> >dmModeReadWrite);
> >
> > if (!dbHandle)
> > {
> > // TODO This will happen if the database has somehow been corrupted
> > // which seems unlikely. How do I gracefully handle this?
> > }
> > else
> > {
> > // ... code that sets the column types in the table and loads
> >the data from the database, etc
> > }
> >
> >What do I put in the if statement to cleanly deal with any problems
> >that may arise? I doubt that this will actually happen because when
> >my application is launched it will create the database if it doesn't
> >exist. However, I don't feel right about just assuming that the
> >database exists and opens without any errors here?
> >
> >I thought that I could just show an Alert here. But how do I make it
> >so my main form is not displayed or otherwise recover from an error?
> >Or is there a better way to handle this?
>
> Pretty much common sense dictates your actions
> here. You probably should look for your DB each
> time and create it if it does not exist. After
> that, if it is missing or does not open, you
> probably have big enough problems that it is a
> "no go" anyway. Put out a dialog to help the user
> resolve the issue and exit gracefully, or
> continue on with reasonable default values.
After posting this message, I found ErrDisplay(), ErrFatalDisplayIf()
and ErrNonFatalDisplayIf(). At the moment I am using these. However,
I will consider writing a auxilliary function that opens the database,
creates it if it doesn't exist, and returns the DmOpenRef when
finished. This still won't solve all problems, especially if the app
is expecting to read from or write to an existing record, but it seems
like it will be helpful in many other situations.
> >4) I am using O'Reilly's "Palm OS Programming" to learn about the
> >Palm OS API. It contains a Table example that loads the data from the
> >database in this MainFormInit() method and stores it in each row of
> >the Table using TblSetRowData(). Then it registers a custom load
> >procedure with TblSetLoadDataProcedure() which reads the string data
> >from the Table using TblGetRowData().
>
> Tables are recognized to be the most difficult UI
> element in Palm OS programming. But they are also
> very useful and the right tool to use many times.
> Some of the class libraries available make them
> simpler to use.
>
> I think your are on the right track with the
> O'Reilly book (Rhodes & McKeehan). That is how I
> learned and I have been well served by that book.
>
> Again, a caveat, (aren't there always?). It is
> now a fairly old book. There are many new APIs
> not really covered, especially in the Tungsten,
> Treo, and LifeDrive generation of devices. But it
> is still the best book from which to "learn the
> ropes".
I bought this book several years ago. I read through most of it but
didn't have a project to put it to use at the time. Now I have a
project idea from a friend that I am trying to use to refresh the
little that I learned when I first purchased the O'Reilly book.
Although I'm not a beginning programmer, I am certainly new to PalmOS
and it's challenges.
> Also,, keep your Adobe acrobat Reader open all
> the time and all the various books to the "My
> Bookself" feature. Especially the "Companions"
> and "Reference".
I agree. The PalmOS Reference has come in quite handy when I can't
find something in the O'Reilly book. In fact, it contains enough
additional information to be useful even if I do.
> >Conceivably, you can implement the custom load procedure to load the
> >data directly from the database itself. Why would you choose one way
> >over the other? What are the performance and efficiency
> >ramifications? Are there any other reasons to prefer one of these
> >methods over the other?
>
> I would start with the vanilla implementation, and get more clever from there.
> I load a 10 row by 6 column table reading from a
> DB (opening and closing DB each time) in one of
> my XxxxFormInit() functions with no perceivable
> delay.
>
> >
> >I apologize for the lengthy email. I will greatly appreciate any
> >suggestions or tips that anyone can provide.
> >
>
> You sound like an intelligent person. I don't
> think you will have much trouble. Palm
> programming is just a little different. Mostly
> from the standpoint of it being a
> "limited-resource" and memory based device. I
> really like it because the whole architecture of
> the system seems to be thought through
> beforehand. Much like the earlier versions of
> UNIX. Some forethought went into the design and
> one you get the get the feel of it, it makes more
> and more sense. It is FAR FAR better than the
> mess in the Windows CE side. Trust me.........
Thanks for the compliment. Like I said, I already have a bit of
programming experience with Windows and Linux/Unix in several
languages. PalmOS has some appeal to me BECAUSE of the limited
resources. I look forward to continue to learn more about Palm
development.
Thanks for the suggestions.
Layne
--
For information on using the PalmSource Developer Forums, or to unsubscribe,
please see http://www.palmos.com/dev/support/forums/
