Menu

#48 QT takes over region ABOVE graffiti area

open
nobody
None
5
2004-06-27
2004-06-27
No

I've seen this problem for a long time, but only just got to
submitting it now.

The quicktype program seems to take over not only the
graffiti area, but also an area ABOVE the graffiti area.
This area is about an entire "row" high, but does not
behave uniformly.

Specifically, a tap in the region up to about one-half a
row height above the template generates a keystroke
correpsonding to the letter directly below it. The region
directly above this (also about one-half row high) seems
to be "dead" -- i.e., a tap there is not recognized by the
running app & also does not generate a keystroke.

But it's not always exactly the same.

In QT's clabration screen, after it is perfectly calibrated, I
can tap *above* the top row & continue to get the
characters in the top row up to a cerrtain point & then I
get just beeps; a bit higher I get nothing.

I currently notice this particularly in Datebk5.1b, where
the bottom half of the Datebk buttons are unusable - I
must remember to tap in the upper half of them. The
scroll-down arrow in the lower right corner of the screen
is virtually inaccessible/unusable, as it is very small & QT
seems to take over that entire region. If I tap too low, I
get the Calculator I've assigned to the upper-right key of
QT. Tap higher - get no-op ("dead" region). A little higher
& sometimes get the down-arrow, but more often this is
high enough to hit the up-arrow.

Another place it gets in the way is when I attempt to
re-calibrate the Palm digitizer. Can't do it without
deactivating Quicktype! The cross on the bottom of the
screen can't be tapped while QT is running! Here the
"dead" region seems to extend even higher. In fact, you
have to reset the Palm to get out of the digitizer
calibration mode & then turn off QT before re-calibrating
the digitizer.

Note:
I am running PalmOS 4.1 on Sony Clie T665C
Quicktype 2.1.0b7
Row height has been set at 10.
Calibration of QT has been done & all keys work correctly
within their allocated regions, with the exception ofthe
top row extending up as noted above and the "dead"
region above the "extension"

Note2: Perhaps I could provide more info for debugging
this if QT would report the input coordinates of taps on
the QT calibration screen as suggested in an enhancment
request I made some time ago.

Discussion


Log in to post a comment.