Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    Page down/up key not working on VLayout

    I noticed that I can't use page up/down to scroll in my VLayout's anymore. I believe this happened when we upgraded to 4.0p (we're using 4.1p on FF26 now). Is there anything I have to call for this to occur?

    #2
    This hasn't changed per se (and is still working as it should in our testing).
    For the scrolling on keypress behavior to work, the layout, or a descendent of the layout must have keyboard focus of course.

    If you have a case which is failing for you, please show us how to reproduce the problem and we'll take a look

    Thanks
    Isomorphic Software

    Comment


      #3
      I looked into it further and it seems that DynamicForms in Tabs do not scroll with page up/down. Here is a simple test case:

      Code:
      DynamicForm form = new DynamicForm();
      form.setItems(new TextAreaItem("1"),
          new TextAreaItem("2"),
          new TextAreaItem("3"),
          new TextAreaItem("4"),
          new TextAreaItem("5"));
      
      Tab tab = new Tab("tab");
      tab.setPane(form);
      
      TabSet ts = new TabSet();
      ts.addTab(tab);
      ts.setWidth100();
      ts.setHeight100();
      ts.draw();
      Last edited by kevboy; 23 Apr 2014, 15:22. Reason: fixed setMembers -> setItems

      Comment


        #4
        The reason for this is that the keys "have meaning" to the form item, and having both the item and the parent widget react to them leads to a confusing user experience.
        For example page-up / page-down are used to scroll a textArea when populated with enough text to require v-scrollbars, so in this situation you wouldn't also want some ancestor canvas to be scrolling up and down as the user is attempting to scroll the form item.

        Comment


          #5
          I totally agree. However, this happens when the user is not focused on the text areas (I just added them because they had a tall height--they can be any form item). In other words, when the user clicks outside the text area and then hits page down, the tab pane doesn't scroll down.

          Comment


            #6
            Checking in to see if there's any word on this.

            And I just wanted to clarify that the user's focus is NOT in the text area when page down/up is pressed. Thus, expected behavior should be that the page scrolls down/up.

            Comment


              #7
              Fundamentally, for all Canvases, for keyboard scrolling to work, keyboard focus needs to be either on the canvas to be scrolled or on a child of it.
              To put focus onto a widget you of course need canFocus to be true, and you need to click the widget, or tab to it.

              In this case, it isn't clear where your focus actually is going from your description. You can use the developer console and look at the focus-target to see where focus actually is.

              Please let us know if that doesn't give you enough information to get this working as you need.

              Comment


                #8
                With my test code, I just clicked next to any text area item. In the dev console, it shows "isc_DynamicForm_0". Its canFocus attribute is true. Still can't scroll with keyboard.

                I've tried it on Chrome 32.0.1700.76 m, GWT 2.6.0, and SmartGWT 4.1p20140420 now and I get the same behavior.

                Any other suggestions? Thanks

                Comment


                  #9
                  Hi again,
                  Just a quick update to let you know this isn't abandoned!

                  The reason this isn't behaving as you are expecting from your description is that when you click on the background of a DynamicForm we don't take focus from whatever item within the form has focus.

                  So you could continue typing in the form item, and similarly the scrolling keys (Arrows, Page Up / Down) are still being passed to the form item (causing local scroll of the text-box) rather than causing the form itself to scroll.

                  We're are discussing internally whether there's a better way to handle this, and will follow up here if we come up with any proposed framework level changes for this.

                  If you need an immediate solution, a workaround would be to add an itemKeyPress handler to the form itself, check the event for the keyName being "Page_Up" or similar (see http://www.smartclient.com/smartgwte...s/KeyName.html) and explicitly call scrollBy on your form in the case where you need it.

                  Regards
                  Isomorphic Software

                  Comment


                    #10
                    Thanks for the update and workaround.

                    I'm not sure if the focus is not on the form item anymore after I click on the background of the dynamic form...

                    I clicked the first text area item. Typed something in it. Then clicked outside of it (note: the blue highlight surrounding the perimeter of the text area item goes away). Tried typing again while outside focus but nothing shows up in it.

                    Comment


                      #11
                      Just wanted to clarify my last post was the behavior from my test code.

                      Comment


                        #12
                        We've come up with a solution we believe will resolve this for you.
                        As of the next nightly build (April 29) in the 4.1p branch (and today's build, April 28, in the 5.0d branch), we have modified the logic in DynamicForm / FormItem to be more intelligent about which keypresses are "swallowed".

                        The new behavior is basically that FormItems will only swallow key events if they really do impact the item.
                        So if you're focused at the end of a scrollable text-area, and you hit "page up", the TextArea will scroll up a page, as expected.
                        But if you're at the top already, the DynamicForm will recieve the event and scroll itself.

                        Similarly with other items - and other keypresses -- for example arrow keys while embedded in a TextItem will move the caret as you'd expect, until you reach the start or end of the item, then they'll be allowed to actually scroll the form itself.

                        Please give it a try with the next nightly build and let us know if you agree that this now behaves as you'd like.

                        Thanks
                        Isomorphic Software

                        Comment


                          #13
                          I tried the new build but it doesn't fix the problem that keyboard scrolling doesn't work at all with a DynamicForm in a TabSet (see my test code posted previously).

                          Comment


                            #14
                            This should be working.
                            Which exact build are you using?

                            Can you show us the complete entry point class to reproduce the problem (we want to be sure where the scrollbars are being dipslayed), and confirm your exact steps to reproduce (which item are you focussing in, which browser are you using)?

                            Thanks
                            Isomorphic Software

                            Comment


                              #15
                              4.1p20140429 on Firefox 26.

                              The test code I wrote in the previous post is the only thing in the entry point in the class.

                              I made the browser window small enough so that vertical scroll bars appeared. Then I loaded the app. I clicked the area to the right of the first text area item (but not inside the text area) and typed page down.

                              Let me know if there's anything else that would help.

                              Thanks

                              Comment

                              Working...
                              X