Jahn,
Nice catch!
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. 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. If you have CSpotRun installed, which also offers HW key
support you will see that it has this bug too, in a similar manner.
The commands to prevent the hardkeys doing a command while menus are
displayed was added in as part of the code patch for autoscroll, since it
needed to be done anyways.
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.
Best wishes,
Robert
> When I tap the menu silk button and then use a button to go back
> or forth to the previous or next page, the page I navigate to
> will only be rendered within the area of the menu that just
> opened, and the rendering will be faulty, i.e., most of the
> screen will still show the old page. This will persist when scrolling.
>
> Easy fix would seem to be to let those hard-key-functions test
> for open menus and close them before performing the actual
> navigation function.
winmail.dat
