Paul Dugas wrote:
>I remembered that the AsciiChart program has a table with taller rows and
>took a look at it. Sure enough! It's got the same problem. Try tapping on
>the bottom half of one of the characters in the table. Try penDown on the
>top of an item them penMove out of the item. See? Silly isn't it? Why
>does it do this?
>
>Clarification: Could the table manager be modified such that when it
>internally calculates the bounds of custom drawn table items, it uses the
>height of the row rather than the height of a single line of bold text?
I consider this a bug. It is visible in the built-in Memo Pad application,
too. The really annoying thing about it is that when you select a large
font, it makes 30% of the table "dead" so that taps in items have no
effect. I sent the following bug report to Palm Dev support:
=============================================================================
Date: 1999-10-27
To: Palm_Dev_Support
From: Bill Goodman <[EMAIL PROTECTED]>
Subject: Two bugs in Table code
In versions of PalmOS through 3.3 the table handling code does not seem
to account properly for a change in the row height. When looking for taps
inside a table item, it seems to ignore the current row height if it has
been changed since the table was created.
To demonstrate, start the Memo Pad application and create several memos.
In the list view, change the font to the largeBold font. Tapping in the
lower 1/3rd of any displayed memo title will not activate the note as it
should. This makes approximately 1/3 of the display area a dead zone which
produces no result when tapped.
---
A possibly related bug is that the TblSetRowHeight function does not
change the height of the item rectangle returned by TblGetItemBounds.
=============================================================================
Y
