ICEpdf
  1. ICEpdf
  2. PDF-85

Rationalize Viewer RI focus management

          Details

          • Type: Improvement Improvement
          • Status: Closed
          • Priority: Major Major
          • Resolution: Fixed
          • Affects Version/s: 3.1
          • Fix Version/s: 4.0 - Beta, 4.0
          • Component/s: Viewer RI
          • Labels:
            None
          • Environment:
            ICEpdf Viewer RI
          • Affects:
            Sample App./Tutorial

            Description

            The Viewer RI application is currently setting focus on the document panel (to support keyboard navigation of the visible document, scroll up, down, etc.) in numerous places, including every-time an actionEvent or itemChangedEvent is fired on the SwingController.

            This approach is too blunt and results in the focus being set many times when it is redundant or undesired. One side-affect of this behavior is that the Search panel is not able to set focus on the search entry field because focus is "stolen" away by some other event that sets focus on the document panel.

              Activity

              Hide
              Permalink
              Ken Fyten added a comment -

              This is fixed. The fix consists of:

              1. Removing redundant calls to "documentViewController.requestViewFocusInWindow();" being made in various locations, such as when opening documents, when the zoom settings change programatically, or when the visible page is updated (view updated), or when the mouse is clicked on the document (when the focus is already set when the mouse is pressed).

              2. It turns out that the only time the "documentViewController.requestViewFocusInWindow();" call is required is when a toolbar button is pressed (either the top or bottom toolbars). Also, when the mouse button is pressed over the document pane itself.

              3. The existing calls to the "documentViewController.requestViewFocusInWindow();" method in SwingController.itemStateChanged were refined to only make the call when an actual selection event occurs, not for every itemChangedEvent that comes through the listener. Also, the SwingController.actionListener was tweaked to not make the focus call if the Search button was pressed. The technique can be extended to other toolbar buttons in the future as necessary.

              Committed revision 19718.

              Show
              Ken Fyten added a comment - This is fixed. The fix consists of: 1. Removing redundant calls to "documentViewController.requestViewFocusInWindow();" being made in various locations, such as when opening documents, when the zoom settings change programatically, or when the visible page is updated (view updated), or when the mouse is clicked on the document (when the focus is already set when the mouse is pressed). 2. It turns out that the only time the "documentViewController.requestViewFocusInWindow();" call is required is when a toolbar button is pressed (either the top or bottom toolbars). Also, when the mouse button is pressed over the document pane itself. 3. The existing calls to the "documentViewController.requestViewFocusInWindow();" method in SwingController.itemStateChanged were refined to only make the call when an actual selection event occurs, not for every itemChangedEvent that comes through the listener. Also, the SwingController.actionListener was tweaked to not make the focus call if the Search button was pressed. The technique can be extended to other toolbar buttons in the future as necessary. Committed revision 19718.

                People

                • Assignee:
                  Ken Fyten
                  Reporter:
                  Ken Fyten
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  0 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: