Entry control expands beyond StackLayout container

I'm using the following (test) code to dynamically create a Page Content. I'm expecting the Entry control to stay within the StackLayout bounds and clip its large Text value. Somehow this doesn't work like I want.

What am I doing wrong here?

<br />    public MyPage() {
            InitializeComponent();

            var stackMain = new StackLayout() {
                Orientation = StackOrientation.Vertical,
                Spacing = 2,
                BackgroundColor = Color.Yellow
            };
            Content = stackMain;

            Padding = new Thickness(15, Device.OnPlatform(25, 5, 5), 15, 10);

            var label = new Label() {
                Text = "Test:"
            };
            stackMain.Children.Add(label);

            var stackEntry = new StackLayout() {
                Orientation = StackOrientation.Horizontal
            };

            stackMain.Children.Add(stackEntry);

            var entry = new Entry() {
                Text = "Blaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
                IsEnabled = false,
                HorizontalOptions = LayoutOptions.FillAndExpand
            };
            stackEntry.Children.Add(entry);

            var button = new Button() {
                Text = "Click me"
            };
            stackEntry.Children.Add(button);
    }
![](https://us.v-cdn.net/5019960/uploads/editor/mi/gnxifpmuvffh.png "")
![](https://us.v-cdn.net/5019960/uploads/editor/29/yuxwh6b3fqu5.png "")

Tagged:

Answers

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    @John_Zwegger

    I've seen other oddities when building UI in C#/code-behind. Its not really the way things are done in the real world.
    For example, more than one person has seen the Map not work right when created in code behind, but is fine when created in XAML.

    You might try building your UI in XAML, test on a physical device not an emulator, and see if it still happens.

    I just ran your same situation, setting the text in XAML so it opens with it, and my Entry doesn't extend beyond the StackLayout

  • @ClintStLaurent said:
    You might try building your UI in XAML, test on a physical device not an emulator, and see if it still happens.

    You're right. Always use XAML .... if possible. In this case I have some dynamic pages; so there's now way around using code. BTW: the problem doesn't occur when I don't use the sub StackLayout (needed to align the button right next to the Entry field).

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    @John_Zwegger

    In this case I have some dynamic pages; so there's now way around using code.

    Hmm... I have plenty of dynamic pages that are in XAML. You just have to have Control Templates that bind back to your data object (model/viewmodel) and lay out your page accordingly. After all, in the end your code-created entry still has to bind back to the viewmodel, right? The text of the label comes from their... and so on.

    Anyway... As a test... Just to see if its a C# created control problem. Wack out a quick static page with the same design and layout and see if it happens there.

  • JohnHardmanJohnHardman GBUniversity mod

    @John_Zwegger - I've just had a play with this on UWP. I'm seeing the same thing. It looks like a XF bug to me. If it hasn't been reported already, do report it at bugzilla.xamarin.com

    BTW - it's not the cause of the problem, but you might want to re-visit the order in which you do things when constructing your UI hierarchy, making the assignment to Content the last thing, not one of the first.

  • JulienRosenJulienRosen CAMember ✭✭✭✭

    XAML pages can be as dynamic as you want them to be. Just going to throw in my 2c that XAML is the way to go.

  • I did some more testing, and now I have an example made fully with XAML in which the problem also is present. Can you tell me what's wrong here?

    <br /><?xml version="1.0" encoding="UTF-8"?>
    <ContentPage xmlns="http://xamarin.com/schemas/2014/forms" 
            xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml" 
            x:Class="Test"
            Padding="10,30,10,10">
    
        <ContentPage.Content>
            <StackLayout Orientation="Vertical">
                <StackLayout Orientation="Horizontal">
                    <Entry Text="xxxx xxxx xxxx  xxxx xxxx xxxx xxxx xxxx xxxx xxxx" HorizontalOptions="FillAndExpand" />
                    <Button Text="Click" HorizontalOptions="End" />
                </StackLayout>
            </StackLayout>
        </ContentPage.Content>
    
    </ContentPage>
    
    

    @ClintStLaurent said:
    @John_Zwegger

    I've seen other oddities when building UI in C#/code-behind. Its not really the way things are done in the real world.
    For example, more than one person has seen the Map not work right when created in code behind, but is fine when created in XAML.

    You might try building your UI in XAML, test on a physical device not an emulator, and see if it still happens.

    I just ran your same situation, setting the text in XAML so it opens with it, and my Entry doesn't extend beyond the StackLayout

  • DirkWilhelmDirkWilhelm USMember ✭✭✭✭

    What happens if you set the HorizontalOptions of your entry just to "Fill" instead of "FillAndExpand"?

  • JohnHardmanJohnHardman GBUniversity mod
    edited February 2017

    @John_Zwegger - As mentioned previously, I had a play with this after seeing your report above. It looks like a Xamarin.Forms bug (I see the same thing on UWP). If you haven't already, report it in Bugzilla.

  • Doesn't make any difference.

    @DirkWilhelm said:
    What happens if you set the HorizontalOptions of your entry just to "Fill" instead of "FillAndExpand"?

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭
    edited February 2017

    @John_Zwegger - I've just had a play with this on UWP.

    @John_Zwegger

    I copy/pasted your StackLayout to the project I've been using for my tutorials as a quick test, running it UWP since @JohnHardman said he could reproduce it there.

    First thing Iearned: You can't deploy to a FAT32 volume, such as a default formatted USB flash drive.
    Next I doubled the amount of text so it would be longer than my UWP window.
    Indeed, the Entry enlarged past the width of the application.
    Is that a bug? The XAML built exactly what was asked of it. We've all seen questions where devs want the page as they asked, not 'fixed' by the system into what it thinks they wanted.

    Next I asked myself, "What good is this? Hardcoding the value of an Entry is pointless if you want to actually get back the user input." You have to bind this to a value on your ViewModel anyway, right? So I changed it to bind to a property whose initial value was that massive string.

            #region BindedUserInput (string )
            private string _BindedUserInput = "xxxx xxxx xxxx  xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx  xxxx xxxx xxxx xxxx xxxx xxxx xxxx";
            public string BindedUserInput
            {
                [DebuggerStepThrough]
                get
                {
                    return _BindedUserInput;
                }
    
                [DebuggerStepThrough]
                set
                {
                    if (_BindedUserInput == value) return;
                    _BindedUserInput = value;
                    OnPropertyChanged();
                }
            }
            #endregion BindedUserInput (string )
    

    Still extended past the width of the window.

    Then I got thinking about how C# is event driven... UI updates and re-renders when values change...
    Q: So what happens when the initial value is string.empty then the value updates?
    A: The control now rendered on the UI updates to display the new value.

            #region BindedUserInput (string )
    
            private string _BindedUserInput;
            public string BindedUserInput
            {
                [DebuggerStepThrough]
                get
                {
                    return _BindedUserInput;
                }
    
                [DebuggerStepThrough]
                set
                {
                    if (_BindedUserInput == value) return;
                    _BindedUserInput = value;
                    OnPropertyChanged();
                }
            }
            #endregion BindedUserInput (string )
    
            protected override void OnAppearing()
            {
                base.OnAppearing();
    
                BindedUserInput = "xxxx xxxx xxxx  xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx  xxxx xxxx xxxx xxxx xxxx xxxx xxxx"; //Doesn't work in the constructor because the page hasn't rendered yet.
            }
    

    Is it a bug... Eh... Probably. The length of the string should have been considered when the UI was initially rendered. Or maybe once the form is done rendering the first time it should do a refresh to fix these things.
    Is it easy to rectify in the meantime? Yeah. With a little proper coding practice half of these issues don't even arise to begin with. I empathize with the guys developing the Xamarin eco-system because they have SO MUCH work do to just making new features: Its really hard to envision all the ways people can do things (many often the wrong way), then code around those things.

    So is this a bug... Yeah... Is it holding you up? Not at all. Or at least it shouldn't be with just a little bit of thought and trial & error to work out a fix.

  • JohnHardmanJohnHardman GBUniversity mod

    @John_Zwegger - @ClintStLaurent is correct. This does seem to be a Xamarin.Forms bug, but it's easy to workaround. You should log it in Bugzilla so that it hopefully gets fixed one day, but then update your code to use bindings. Admittedly, there are scenarios where you won't want to use bindings, but I suspect this is not one of them.

  • John_ZweggerJohn_Zwegger USMember
    edited February 2017

    -deleted-

  • tomahawk1277tomahawk1277 Member

    I had the same problem with a horizontal StackLayout that had an Entry followed by a button. Long strings would (in certain cases, depending on how the screen was loaded) push the entry past the edge of the screen, making the button next to it disappear. I fixed it by changing the StackLayout to a Grid with two columns: one with a "*" width (for the entry box) and the other with an "Auto" width (for the button).

Sign In or Register to comment.