The Palm OS’s display system had to undergo three mayor overhauls in the last few years – dynamic UI(long time ago), HiRes+ and 5way navigation. The path to dynamic UI was very, very buggy afaik, HiRes+ worked well and 5way nav is, umm, more like dynamic UI to me.
Anyways, I had a nice modal form that reacted to WinDisplayChangedEvents. That form was popped up via FrmPopupForm(the only such form in the entire app…all others worked fine =) ). The resizing didn’t quite work out on Chris Schrinner’s TX:
There seems to be some kind of quirk with PalmOne engineers having placed a cache into their 5way nav system that stores whats behind the blue ring. Now, when the form gets resized, this cache somehow screws up and distorts/obfuscates the proximity of the poor control that happened to be selected.
Fixing the problem is rather simple – remove the focus, do the movement and then restore focus. Here is how I did it(no special headers needed btw):
UInt32 buffer;
Err err;
err = FtrGet(sysFtrCreator, sysFtrNumFiveWayNavVersion, &buffer);
if (err == errNone)
{
// One-handed navigation is supported
buffer=FrmGetFocus(pForm);
FrmSetFocus(pForm,noFocus);
FrmNavRemoveFocusRing (pForm);
}
//Party with the controls here
if(err==errNone && buffer!=noFocus)
{
FrmSetFocus(pForm,buffer);
}
FrmDrawForm(pForm);
P.s. I know that this code doesn’t detect the Treo 600 as 5way capable. But since the Treo 600 has no HiRes+ screen, I don’t really care as it will never see this code anyways….
Related posts:
This is documented by Palm in their SDK.
From the Palm Developer Guide in SDk-5.3 section 9.9.9.3:
——————————————–
9.9.9.3 Focus rings and redraw problems
An application may run into redraw problems when it controls the drawing and/
or removal of focus rings (when they directly call HsNavDrawFocusRing() and/or
HsNavRemoveFocusRing()).
Drawing focus rings around an object and properly restoring an object when it
loses the focus ring is very tricky. The rings can be drawn over an object’s frame,
over another object, and over pixels directly drawn to the screen. When the
system draws and removes the ring, it takes these possibilities into account and
also contends with clipping rectangles and objects that change appearance
between receiving and losing the focus ring. The system manages these
complications fairly well when it is controlling the drawing and removal of rings.
For an application to properly handle these complications, developers should
have a basic understanding of the ring drawing and removal mechanism. Before
a ring is drawn, the bits behind the ring are saved. When a ring is removed, the
bits behind the ring are restored, the object is redrawn, and the portion of any
object that was behind the ring is redrawn.
Therefore, it is important that an application always draw an object in its normal
state before drawing a focus ring around it. If the appearance of an object with the
focus ring needs to change (that is, if an object’s bounds needs to change) or if
what’s behind the focus ring needs to change (for example, if the background
color of the form needs to change), an application should remove the ring, make
the changes, draw the changes, and then draw the ring again.
———————————————-
Hi,
a little hint for the OnBoardC afficionados.
pasting as FrmDrawForm below the FrmNavRemoveFocusRing (pForm);
makes the code work in OBC too – at least it did for Daily Quote!
Best regards
Tam Hanna
Thanks.This tips are great.