Announcement

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

    canvas scrollTo

    Below is a sample of calling scrollTo on a canvas. Scroll down to where the button is. Click on the button. I expect it to scroll back to the top but it does not. What am I missing?

    Code:
    isc.HLayout.create({
        ID: "hLayoutAlignCenter",
        autoDraw: true,
        // Specifying the width creates space within which to
        // center the members.
        width: "100%",
        height: 700,
        layoutMargin: 6,
        membersMargin: 6,
        border: "1px dashed blue",
        align: "center",  // As promised!
        members: [
            isc.VLayout.create({
                height: 1200,
                width: 40,
                backgroundColor: "red",
    members:[isc.LayoutSpacer.create({height:"90%"}),isc.Button.create({click:function(){hLayoutAlignCenter.scrollTo(0,0);} })]
            })
        ]
    });

    #2
    In this example, the layout (hLayoutAlignCenter) doesn't have "overflow" specified to show scrollbars -- it's defaulting to overflow:"visible", so any scrollbars you see are coming from some parent of this widget. As such he layout isn't scrolled to reveal the button, its parent is, and the 'scrollto' call would have no effect.

    If you set 'overflow:"auto"' on the layout, this should work for you.

    Comment


      #3
      I could've sworn I was testing with overflow:auto - oh well. That works, thanks!

      Comment


        #4
        I have this problem when I call Canvas.scrollTo, I can see that scrollTo is being called with my coordinates (0,0) but then right after, I see a printout for scrolling again. I'm not moving the mouse in between - as you can see the scroll call are not that far apart from each other in time. How can I debug this?


        12:32:26.043:DEBUG:scrolling:page$$vLayout:scrollTo(0, 0), reason: undefined
        12:32:26.094:SCR0:DEBUG:scrolling:page$$vLayout:scrollTo(0, 493), reason: nativeScroll

        Comment


          #5
          I think this might be due to focusing on editable fields - I'll try to recreate a scenario

          Comment


            #6
            This is likely a focus issue, yes. When a DOM element receives keyboard focus, the browser scrolls it into view automatically.

            Not sure exactly what your use case is. One option may be to use "delayCall" to scroll after the click thread completes - this ensures focus is already in the clicked, focusable element when the scroll occurs.
            However we don't know enough about your app to guarantee this approach makes sense for you. If you can't get things working, show us a test case and we'll let you know what we think

            Thanks
            Isomorphic Software

            Comment


              #7
              I was able to solve my problem with a timer - is delayCall pretty much the same thing?

              Comment


                #8
                Yes - it's a timer.
                Docs here:
                http://www.smartclient.com/docs/8.0/...lass.delayCall

                Comment

                Working...
                X