> This was a bug that I guess had been slipping through for awhile, and I
> only came across it myself when looking at the things needed for
> enabling/disabling autoscroll.
As Mike would say "...not a bug, a feature!..."
Seriously though, I came up with one (hacky) solution to this, but
it needs to be dealt with properly. One way around this is to have the
hardkey event stuff EvtQueue with another menu press, so that a user hits
menu (the menu pops up) and then hits a hardkey (which is pre-empted by
another menu press which closes the menu) and then gets his intended action.
The problem here is that if you simply hit the hardkey without tapping the
Menu button, you get the same behavior without wanting it. Clearly this
needs a proper solution. Since we can't (without rewriting our own internal
menu handler) deal with the focus model, we have to come up with a more
clever way to do this.
What about something like:
FrmSetFocus(form, FrmGetObjectIndex(form,
frmMainTop));
..when the hardware button is pressed. The OS itself seems to have a
fldEnterEvent and fldChangedEvent, but no fldExitEvent (which you can find
in include/Core/UI/Event.h). I might be offbase here with regard to fld* vs.
frm*, but.. seems the OS is lacking in some key areas.
I used to use PalmTelnet with my GPS to debug the communications
(before Palm decided to change the port and clip-on design on me, making my
two Rand McNally GPS units useless, thank you Palm), and when I tapped the
menu button while there was data scrolling in the window, the menu would be
"painted" on the scrolling output, and then roll up of the screen in time
with the scrolling output. It has since been fixed, but I'm not sure if the
ptelnet.prc sources are available to see how he got around this. Perhaps
someone could email the author and find out.
Incidentally, this *cough* "feature" *cough* exists with Gestures as
well, so it's something we should definately work on a fix for.
> The reason for the bug is that when a menu is displayed, the menu
> becomes the active draw window, so unless button support is killed while
> a menu is displayed, the button will start a draw, and draw to the menu
> window.
Would SaveBehind help us here on the menu resource?
> For draw windows, there was another (and probably rarer!) bug that was
> related, that if one is viewing a full scale (pannable) image in the
> viewer, and enter the command shortcut to change the toolbar from top to
> bottom, the viewer will go down with a fatal crash. I may have added a
> line to deal with that case, but I don't remember. I don't know how many
> people are going to get a hankering to change the toolbar from top to
> bottom while scrolling around on a pannable image, in which one can't
> see any toolbar anyways.
In my opinion, which differs from Mike's, a crash is a bug, no
matter how rare the situation or circumstances that can cause it to happen.
This is why we have gremlins.
I'd rate the former as a higher-priority fix than the latter, but
eventually, both should be attended to.
--------------------. pgp://7075AE4A ,-. pilot-link plucker
David A. Desrosiers \ ,---------------------' \ sourcefubar cvs
gnu-designs.com, Inc. `--' hacker at gnu-designs.com `---------------------
