locked
ScrollView does not autoscroll for Editor when keyboard appears RRS feed

  • Question

  • User31763 posted

    I have a simple test based on the code in this post:

    var layout = new AbsoluteLayout();
    layout.Children.Add(new Entry(), new Rectangle(0, 1, 1, -1), AbsoluteLayoutFlags.YProportional | AbsoluteLayoutFlags.WidthProportional);
    
    var page = new ContentPage { 
        BackgroundColor = Color.Gray,
        Content = new ScrollView {
            Orientation = ScrollOrientation.Vertical,
            Content = layout
        },
    }; 
    

    this works correctly, and the view is scrolled when the keyboard appears. However, if you change Entry to Editor, the scrolling no longer happens.

    Has anyone found a workaround for this?

    Monday, June 9, 2014 9:47 PM

All replies

  • User1004 posted

    Hi Nathan, thanks for the report. this is a known issue we're working on.

    Tuesday, June 10, 2014 7:48 AM
  • User56183 posted

    I got trapped in this situation too... waiting for the fix! thanks!

    Wednesday, June 18, 2014 1:23 AM
  • User56183 posted

    Still no fix for this bug? I need it right now! :D

    Tuesday, July 29, 2014 12:03 AM
  • User4236 posted

    Is there an ETA for this fix?

    Saturday, August 23, 2014 11:21 AM
  • User4024 posted

    Still nothing? Im also trying to fix this. I found a workaround by placing a boxview in the end just after entry and stretching it when the keyboard opens or closes. http://stackoverflow.com/questions/24353159/scroll-editor-in-xamarin-forms-into-view

    Friday, September 5, 2014 5:06 PM
  • User22038 posted

    Does anyone have any information on this one? We also ran into this today.

    Monday, October 13, 2014 3:34 PM
  • User987 posted

    Any info available?

    Thursday, October 23, 2014 2:57 PM
  • User67149 posted

    Any update to this request ? I also want to autoscroll while editor is inside the stack and stack is inside the scrollview.

    Monday, October 27, 2014 1:28 PM
  • User22276 posted

    bump

    Sunday, November 16, 2014 4:46 AM
  • User74085 posted

    Same here, waiting for a fix date

    Tuesday, November 18, 2014 9:09 PM
  • User65389 posted

    Hi all

    In my page, I use SearchBar's instead of Entry's .
    This has worked before Pre-1 (the page was scrolled automatically, so that the SearchBar was shown on top of the keyboard).
    This don't work anymore with Pre-1 on iOS (iPhone and iPad) and also no more on Android (tablet).
    I have filled a bug in bugzilla to this bug.
    Link: https://bugzilla.xamarin.com/show_bug.cgi?id=24640 I also have posted various other (old and new bugs).
    Short descriptions and links see here: forums.xamarin.com/discussion/27957/listview-on-android-occasionally-displays-the-wrong-image#latest

    Wednesday, November 19, 2014 12:03 PM
  • User74518 posted

    I had this issue too, and just manually anmated it (its super simple)

    just call on your element focus event

    Editor.GotFocus+=(s,e)=>{ YourMainLayout.TranslateTo(0,-40,100) }; //values are relative which is super cool!

    Editor.LostFocus+=(s,e)=>{ YourMainLayout.TranslateTo(0,0,100) }; //0 set it back to its default position

    Wednesday, November 19, 2014 1:27 PM
  • User65389 posted

    @NadjibB?:
    Thanks for your suggestions, but as I wrote, I use SearchBar (not Entry) and this has worked without problems before update to Pre-1. I further already have placed a bug-description in bugzilla. I think, Xamarin have to solve the bug instead that every XF-developer has to implement workarounds for that bug (and.. after the bug is fixed, you then have to remove the workaround, at every place you have used it;-)
    However - thanks anyway...

    Thursday, November 20, 2014 8:45 AM
  • User63744 posted

    Half a year later and still no fix ...

    @NadjibB? This workaround is very unreliable as it uses a fixed value. If the Editor is positioned lower/higher than that value it will never scroll into view.

    And the workaround that @Serra posted doesn't work for me. When I resize the placeholder the ScrollView simply remains at its current position so the Entry is still out of view.

    If anyone has a working workaround, I'd greatly appreciate it. Or just any suggestion that can help me have a working UI.

    Monday, December 1, 2014 3:25 PM
  • User89714 posted

    @StephaneDelcroix - Could you confirm the bug number for this one please, and the latest status. I think this is the same problem I have encountered this afternoon.

    Many thanks,

    John H.

    Friday, April 3, 2015 3:34 PM
  • User112706 posted

    Hi, I'm using the version 1.4.2.6359 and I still have this problem.

    Any news?

    Tuesday, June 9, 2015 11:28 AM
  • User65389 posted

    I have filled a bug three months ago here: https://bugzilla.xamarin.com/show_bug.cgi?id=27789

    The problem is - I think - that the bug don't occurs in general.
    In my case, I only have it on an Android Tablet SMT900 on a complex page, while I don't have it (with the same page) on any Android-Phones. Further, it seems that it only occurs in some special layout-combinations (I have relatively similar pages, where it also works on the Tablet). I have submitted my project for investigation, but it seems as they don't have looked at it yet.

    Tuesday, June 9, 2015 11:57 AM
  • User65389 posted

    @NathanWilliams, @StephaneDelcroix, @PippoCane, @MichaelStrong, @DaveTodaro.5770, @JohanKarlsson.6515, @Rupesh_Tiwari, @TimCromarty, @DanielP, @JohnHardman, @Waltricke:

    I want to ship my Android-App to the store (iOS-App is shipped to the Apple-store, two days ago :smiley: ). I still have this problem (ScrollView is not scrolled automatically, if an entry at the end of the ScrollView receive the focus -> so the user see... nothing if he type in text...) on my Android tablet Samsung SM-T900 while it works on Android phones and on all other platforms.

    I have tried once again for hours to solve the problem - unfortunately without success...: :disappointed:
    - Overtake layout-options from another page, that do the scroll - On the problem-page, I have a StackLayout with: - a button-StackLayout (that have to stay on top -> not scrollable) -> That's a difference to the other page that do the scroll... - a ScrollView with a StackLayout with various Labels, Buttons, Edit's - the XLabs PopUp control (for various PopUps) - added some dummy labels under the entry's (so that the entry's are not the last controls on the page) - add a standard-entry under my "user-object-entry's" -> also do no scroll - removed my "user-object-entry's" and leave only the standard-entry -> also do no scroll - removed the XLabs PopUp control (only to be sure -> also do not scroll -> that's not the problem) - checked, that the newest firmware-version is installed o the tablet Nothing works... :tired_face:

    Do anybody of you have new information's to the problem?

    Thanks...

    Monday, July 6, 2015 1:00 PM
  • User65389 posted

    Update:

    I have done some further test's (including removing the "Button-Stack" (-> also don't work)).

    I have implemented an (ugly, but working) workaround now myself... First, I had to enhance my user-control-entry, so that new also the focused-event is exported (if you use a standard Entry control, you have the event per default :wink:)
    Then I create a dummy-BoxView and add it - only for Android tablets at the end of my StackLayout (under the Entry's).

    var DummyBox = new BoxView { HeightRequest = 380 };
    //
     if (Device.OS == TargetPlatform.Android) // Only for Android tablets
      {
        if (Device.Idiom == TargetIdiom.Tablet)
          { SuchenStack.Children.Add(DummyBox); }
        }
    

    Then I capture the focused-events of the two controls and scroll the ScrollView myself (as the "Autoscroll also don't work with the additional BoxView :disappointed:) :

    oEntrySucheAnbieter.Focused += async (sender, e) =>
     {
        if (Device.OS == TargetPlatform.Android) // Only for Android-Tablets
          {
                if (Device.Idiom == TargetIdiom.Tablet)
                {
                   double iScrollPosition = oEntrySucheAnbieter.Y;  
                     await oScrollView.ScrollToAsync(0, iScrollPosition, true);
                 }
           }
     };
     //
    oEntrySuchbegriff.Focused += async (sender, e) =>
     {
          if (Device.OS == TargetPlatform.Android)   // Only for Android-Tablets
           {
             if (Device.Idiom == TargetIdiom.Tablet)
               {
                  double iScrollPosition = oEntrySuchbegriff.Y; 
                   await oScrollView.ScrollToAsync(0, iScrollPosition, true);
                }
              }
     };
    

    First I had added the BoxView with Isvisible = false and then set Isvisible = true in the focused-events... but as it looks also O.K. if the "invisible" BoxView is "visible" per default -> more "black space" at the end of the page) I finally add it with visible = true.

    For me a clear bug in XF (in combination of Android + Tablet (maybe only Samsung SM T900 - I only have this one :wink:) and a special layout (as the "autoscroll" also work on another page with the SM T900 and Entry's).

    So... ugly, but working workaround (and only for Android-Tablet's).... Now, I start to ship my App also for Android :sunglasses: :sunglasses:

    Hope this helps someone... :smiley:

    Monday, July 6, 2015 3:27 PM
  • User49366 posted

    Still an issue with 1.4.3 - iOS

    Tuesday, July 14, 2015 8:02 PM
  • User49366 posted

    Forms 1.3.0 release notes claim "iOS - Editor now scrolls to the correct location when a keyboard is shown" but as per this discussion I don't think that is true, and I don't know what their test case is.

    I come up with a hack that makes Editors usable on iOS, similar to the one by @nadjibus above, but for Forms 1.4.3:

    ``` var editorScrollView = new ScrollView () { HorizontalOptions = LayoutOptions.FillAndExpand, VerticalOptions = LayoutOptions.FillAndExpand, IsClippedToBounds = true, //? Content = editor };

            this.Children.Add (new ContentPage {
                Title = "Notes",
                Content = editorScrollView
            });
    
            if(Device.OS == TargetPlatform.iOS) {
                editor.Focused += (s,e)=>{ 
                    editorScrollView.ScrollToAsync(0,y,false);
                }; 
    
                editor.Unfocused += (s,e)=>{ 
                    editorScrollView.ScrollToAsync(0,0,false);
                }; 
            }
    

    ```

    However, the user has to manually scroll the control. The editor does not scroll as you type more lines.

    Tuesday, July 14, 2015 9:08 PM
  • User125919 posted

    I was considering forms but, after reading this thread, I'll stay away from it.

    Friday, May 20, 2016 9:38 PM
  • User987 posted

    @FernandoRocha said: I was considering forms but, after reading this thread, I'll stay away from it.

    This is a very old issue and it shouldn't affect your choice whether or not forms is the way to go or not.

    Monday, May 23, 2016 11:13 AM
  • User65389 posted

    @johankson: Unfortunately, the problem @FernandoRocha has, is only one out of many problems... There are new bugs and evergreen-bugs (once solved an then "re-popped") by almost every update. So... I can live with "old bugs" like this, but I can't live with new and evergreen-bugs by every new update (you just have to read the update-threads to see that).
    I work with .forms since about 18 months and (fortunately) have my (working) app's in all stores.
    Since I work with .forms nothing has changed to the stability...
    So I build my next app with Xamarin.Android only (what should be really stable). For me it's unbelievable, how Xamarin (ahh... now MS) can sell (ahh now give away) such a unstable product and do nothing (until now) to make it stable!
    But... don't understand me wrong... I really would love .forms, once it becomes stable.

    I now really hope, that MS would do the job and create a real stable .forms. As soon as this does happen, I will restart develop with .forms.

    Monday, May 23, 2016 11:47 AM
  • User987 posted

    I've created many apps with forms and have yet to encounter a show-stopper bug. Since you can work around almost every issue you have. So falling back to creating the separate GUI for each platform is more work than small workarounds in my view. Also finding these bugs will help to achieve stability in the long run. Just sitting around waiting for frameworks you love to become stabile is a strange approach to getting forward in my point of view.

    Personally I'm prepping a bunch of PR with stuff that I've found over the last few months. If I didn't push through, these bugs would be unfixed for even longer.

    Monday, May 23, 2016 12:18 PM
  • User65389 posted

    @johankson: You should read my posting exactly and inform you a bit better... For my new project, only Android is needed - so I take Xamarin.Android instead of .forms. I have tried what I can, to help Xamarin make .forms stable in the past - you would see that, if you click my profile and see the various threads, like e.g. this one here: https://forums.xamarin.com/discussion/41588/how-to-make-forms-stable#latest (note: this thread was prevented from pop thru Xamarin months ago)

    So I know what I am talking about. Maybe you have the time to check your app on all platforms after every .forms update, find out what don't work anymore and think about how to fix it. Maybe you also want to explain your customer why his app don't work anymore after an update (if you have overseen a bug by your tests)... I have don't have the time (and also don't have the nerves) to do this anymore...

    Monday, May 23, 2016 12:35 PM
  • User987 posted

    I have no doubt you know what you are talking about. I have extensive automated GUI-testing and unit testing on my apps (my customers apps). That helps a bit. I also don't update forms aimlessly on projects unless I have to or that a feature is needed. At that point I do an extensive test on the app. And it's really in 99% of the time two platforms that the customer wants, (iOS and Android).

    I've read the entire post and a lot of your threads as well. I also happen to know what I'm talking about.

    Still my time with checking and fixing forms issues still is less than writing dual GUIs, mostly due to the automated GUI-tests.

    Monday, May 23, 2016 1:15 PM
  • User125919 posted

    @johankson said: I've created many apps with forms and have yet to encounter a show-stopper bug. Since you can work around almost every issue you have. So falling back to creating the separate GUI for each platform is more work than small workarounds in my view. Also finding these bugs will help to achieve stability in the long run. Just sitting around waiting for frameworks you love to become stabile is a strange approach to getting forward in my point of view.

    Personally I'm prepping a bunch of PR with stuff that I've found over the last few months. If I didn't push through, these bugs would be unfixed for even longer.

    That was all I needed to hear, thanks :smiley:

    That's what xamarin forms is to me... A big "work around"...

    Monday, May 23, 2016 1:49 PM
  • User987 posted

    Fair enough! :)

    I'm a bit of a tinkerer. So my view might differ from others.

    Having all that said, pick the tools that works for you. I hope as mentioned above that MS will put some of their expertise into this.

    Monday, May 23, 2016 2:38 PM
  • User89714 posted

    Even with experienced developers, views will differ. We have our own experiences with Xamarin.Forms, and we have our own environments in which we operate.

    Over the same sort of period as @FredyWenger , I have encountered many of the same issues as Fredy. I've logged 64 XF bugs in bugzilla in that time (many of which still have not been fixed), but hit many more that others reported before me. I've done major workarounds due to fundamental issues, and been blocked almost completely (as was Fredy) by one particular XF update. I've stuck with XF for my current project and will continue to do so for this particular project, as I am targeting Android, iOS, UWP, and currently WinRT. Over the last 18 months, XF has improved significantly, and is pretty stable on Android and iOS (there are still some nasties lurking around ListView on Android, but not many). On UWP and WinRT though, the situation is still very different. There are bugs on those platforms that would still prevent me from releasing, and that waste a lot of time during development and testing. Even today, I have hit a fundamental issue, whereby having two views bound to the same property on WinRT and UWP does not work. Combine that with images not displaying in a grid inside a listview and it is clear that the current version of XF on WinRT and UWP is not ready for me to release my app on those platforms.

    As per both @johankson and @FredyWenger, I have created a lot of workarounds as well as spending time creating repro samples. As I quit my previous job to work on creating apps of my own for sale, every day I lose to creating workarounds or investigating XF bugs, is a day that hurts my pocket. For developers being paid by other people, that may be less of an issue, although there will be pressure to deliver in those environments, even if delays don't affect how much money developers make in those environments. For me, after 18 months, it is still unclear whether using XF rather than building native apps for 4 different platforms is a time-saver or a time-waster. I can confidently say that I have spent multiple months investigating and working around XF problems in that time. The danger for me though is that another company might create something similar to what I am working on and get it to market before XF is ready enough for me to release across all of those platforms.

    So, whether XF is the right decision for anybody, depends on multiple factors. There is no single answer, and often no easy answer.

    Monday, May 23, 2016 2:46 PM
  • User65389 posted

    @JohnHardman: Hi John and thanks for your posting. You've hit the nail on the head - nothing mor to say :smile:

    Monday, May 23, 2016 2:50 PM
  • User987 posted

    @JohnHardman Well put! Thanks for the comment!

    Monday, May 23, 2016 2:56 PM
  • User125919 posted

    @JohnHardman yep!

    Monday, May 23, 2016 5:44 PM
  • User179286 posted

    All fine, but is there any work arround?

    Tuesday, May 24, 2016 8:13 AM
  • User125919 posted

    Our problem was solved in a different manner. The whole issue was with our carousel view that was recreating the page when we clicked the text view.

    The text vies scrolls automatically, now.

    Thursday, May 26, 2016 7:33 PM
  • User21407 posted

    @ThomasBurkhart said: All fine, but is there any work arround?

    Looks like this is working correctly now.

    I've taken NathanWilliams original code from the first post and it works in Xamarin.Forms 2.0.1.6495 & 2.2.0.45 I tested on iPhone 6, iOS 9 (iOS Simulator) and Nexus 4, Lollipop (Xamarin.Android Player)

    Tuesday, May 31, 2016 10:05 PM
  • User179286 posted

    Thanks for the Update

    Wednesday, June 1, 2016 7:15 AM
  • User181025 posted

    still an issue with 2.3.1.113-pre3

    Saturday, July 23, 2016 10:22 AM
  • User122934 posted

    I had a similar but different issue that I was able to fix. I wanted to allow the user to click an Editor and have it expand open so they could type in it.

    When the user clicks on the screen, I hide the disabled Entry that is shown on top and the hidden ContentView that has the GestureRecognizer, I display my Editor, increase the Editor.HeightRequest, and then try and set the Focus().

    This is all contained in a ScrollView and works great on Android.

    Most of the time on iOS the keyboard completely covers the Editor and never scrolls down, now and then the Editor never receives Focus.

    To fix this I added a Task.Delay(500); between increasing the Editor.HeightRequest and executing Editor.Focus(). Obviously you could play with the delay milliseconds:

    XAML:

    <Grid>
    
    ....
    
    <Entry x:Name="DisabledEntry"
               InputTransparent="True"
               HorizontalOptions="Start"
               VerticalOptions="Start"
               Grid.Row="2"
               Grid.Column="0"
               Grid.ColumnSpan="2"/>
    
    <ContentView x:Name="HiddenEditorContentView"
                           Grid.Row="2"
                           Grid.Column="0"
                           Grid.ColumnSpan="2">
        <ContentView.GestureRecognizer>
            <TapGestureRecognizer Tapped="OnAnswerListOkButtonClicked"/>
        </ContentView.GestureRecognizer>
    </ContentView>
    
    <Editor x:Name="ExpandingEditor"
                 IsVisibile="False"
                 MinimumHeightRequest="50"
                 Grid.Row="3"
                 Grid.Column="0"
                 Grid.ColumnSpan="3"/>
    </Grid>
    

    Code-Behind:

    private async void OnAnswerListOkButtonClicked(object sender, EventArgs eventArgs) { //In my real code I do not use a TapGestureRecognizer for this, which is why I am not using the 'sender' variable below
        HiddenEditorContentView.IsVisible = false;
        DisabledEntry.IsVisible           = false;
        ExpandingEditor.IsVisible         = true;
    
        ExpandingEditor.HeightRequest = Device.OS == TargetPlatform.Android ? ExpandingEditor.Height + 10 : 50;  //Android assigns a height to the Editor even when IsVisible is false, iOS does not until later, so we just hard code it for iOS
        await Task.Delay(100);
        ExpandingEditor.Focus();
    }
    
    Friday, October 21, 2016 10:30 PM
  • User181338 posted

    Still seems to be an issue in 2.3.3.165-pre4. Adding a scrollview to my page with entries and an editor has hidden all of the entry fields and doesn't scroll.

    Thursday, November 10, 2016 11:26 AM
  • User179286 posted

    Just stumbled about this here https://github.com/paulpatarinski/Xamarin.Forms.Plugins/tree/master/KeyboardOverlap Haven't tried it myself but could be worth a try

    Thursday, November 10, 2016 11:38 AM
  • User147638 posted

    This seemed to be the only solution that worked for me:

    @TrevorCox said: Forms 1.3.0 release notes claim "iOS - Editor now scrolls to the correct location when a keyboard is shown" but as per this discussion I don't think that is true, and I don't know what their test case is.

    I come up with a hack that makes Editors usable on iOS, similar to the one by @nadjibus above, but for Forms 1.4.3:

    ``` var editorScrollView = new ScrollView () { HorizontalOptions = LayoutOptions.FillAndExpand, VerticalOptions = LayoutOptions.FillAndExpand, IsClippedToBounds = true, //? Content = editor };

            this.Children.Add (new ContentPage {
                Title = "Notes",
                Content = editorScrollView
            });
    
            if(Device.OS == TargetPlatform.iOS) {
                editor.Focused += (s,e)=>{ 
                    editorScrollView.ScrollToAsync(0,y,false);
                }; 
    
                editor.Unfocused += (s,e)=>{ 
                    editorScrollView.ScrollToAsync(0,0,false);
                }; 
            }
    

    ```

    However, the user has to manually scroll the control. The editor does not scroll as you type more lines.

    Friday, April 21, 2017 8:30 AM