Xamarin Forms 1.3 Behavior Binding Bug

jonathanyatesjonathanyates jonathan yatesGBMember ✭✭✭

I have been playing with the new Bahavior class in 1.3 and discovered a bug when using Binding on a BindableProperty. I created the following behavior to allow an ItemsSource and an ItemTemplate to be attached to a StackLayout.

public class ItemsSourceBehavior : Behavior<StackLayout>
{
    private StackLayout _stackLayout;

    public static readonly BindableProperty ItemsSourceProperty = 
        BindableProperty.Create<ItemsSourceBehavior, IEnumerable>(p => p.ItemsSource, null, BindingMode.Default, null, ItemsSourceChanged);

    public IEnumerable ItemsSource
    { 
        get { return (IEnumerable)GetValue(ItemsSourceProperty); } 
        set { SetValue(ItemsSourceProperty, value); } 
    }

    public static readonly BindableProperty ItemTemplateProperty = 
        BindableProperty.Create<ItemsSourceBehavior, DataTemplate>(p => p.ItemTemplate, null);

    public DataTemplate ItemTemplate
    { 
        get { return (DataTemplate)GetValue(ItemTemplateProperty); } 
        set { SetValue(ItemTemplateProperty, value); } 
    }

    private static void ItemsSourceChanged(BindableObject bindable, IEnumerable oldValue, IEnumerable newValue)
    {
        var behavior = bindable as ItemsSourceBehavior;
        behavior.SetItems();
    }

    private void SetItems()
    {
        _stackLayout.Children.Clear();

        if (ItemsSource == null)
            return;

        foreach (var item in ItemsSource)
            _stackLayout.Children.Add(GetItemView(item));
    }

    private View GetItemView(object item)
    {
        var content = ItemTemplate.CreateContent();
        var view = content as View;
        view.BindingContext = item;
        return view;
    }

    protected override void OnAttachedTo(StackLayout bindable)
    {
        base.OnAttachedTo(bindable);
        _stackLayout = bindable;
    }
}

However the BindableProperties never get set when using a Binding expression in Xaml like this.

                <ScrollView Orientation="Horizontal">
                    <StackLayout Orientation="Horizontal">
                        <StackLayout.Behaviors>
                            <behaviors:ItemsSourceBehavior ItemsSource="{Binding WeatherPeriods}" ItemTemplate="{StaticResource itemItemplate}" />
                        </StackLayout.Behaviors>
                    </StackLayout>
                </ScrollView>

Notice here that ItemsSource uses a Binding expression and ItemTemplate uses a DataTemplate as a StaticResource. The ItemTemplate does get set but the ItemSource does not. I discovered that the BindingContext on the Behavior never gets set and therefore the ItemsSource is unable to evaluate the BindingExpression. A workaround for this is to set the BindingContext of the Behavior to the BindingContext of the StackLayout when its BindingContext changes like this:

    protected override void OnAttachedTo(StackLayout bindable)
    {
        base.OnAttachedTo(bindable);
        _stackLayout = bindable;

        bindable.BindingContextChanged += (sender, e) =>
            BindingContext = _stackLayout.BindingContext;
    }

Now ItemsSourceChanged gets called as a result of the BindingContext being set.

Please let me know if there is a better solution to this.

Posts

  • YortYort Yort USUniversity

    Thanks for posting this, good to know I'm not the only one suffering from this issue. Have you filed a bug report in Bugzilla or had any feedback from the Xamarin team?

  • YortYort Yort USUniversity

    I couldn't find a bug report in Bugzilla (and I feel this is a bug - Xamarin can advise if not), so I filed one here;

    https://bugzilla.xamarin.com/show_bug.cgi?id=26521

  • StephaneDelcroixStephaneDelcroix Stephane Delcroix USInsider, Beta ✭✭✭✭

    Behaviors and Triggers are meant to be shared (often through Styles), so you can't rely on BindingContext being unique. For the same fashion, it's not right to keep a reference to _stackLayout as it would cause issue at reuse time.

    So, basically, when you use a Trigger or a Behavior, don't handle that as if it was a BindableObject and you'll be fine.

    Here's my quick fix to your Behavior (doesn't support changing the ItemTemplate or ItemSource):

    public class ItemsSourceBehavior : Behavior<StackLayout>
        {
            public BindingBase ItemsSource { get; set; }
            public BindingBase ItemTemplate { get; set; }
    
            static readonly BindableProperty ItemsSourceProperty = 
                BindableProperty.CreateAttached ("ItemsSource", typeof(IEnumerable), typeof(ItemsSourceBehavior), default(IEnumerable), 
                    propertyChanged: ItemsSourceChanged);
    
            static readonly BindableProperty ItemsTemplateProperty = 
                BindableProperty.CreateAttached ("ItemsSource", typeof(DataTemplate), typeof(ItemsSourceBehavior), default(DataTemplate));
    
            static void ItemsSourceChanged(BindableObject bindable, object oldValue, object newValue)
            {
                ItemsSourceChanged ((StackLayout)bindable, (IEnumerable)oldValue, (IEnumerable)newValue);
            }
    
            static void ItemsSourceChanged(StackLayout layout, IEnumerable oldValue, IEnumerable newValue)
            {
                layout.Children.Clear ();
    
                var template = layout.GetValue (ItemsTemplateProperty) as DataTemplate;
                if (template == null)
                    return;
                foreach (var item in newValue) {
                    var content = (View)template.CreateContent ();
                    content.BindingContext = item;
                    layout.Children.Add (content);
                }
            }
    
            protected override void OnAttachedTo(StackLayout bindable)
            {
                base.OnAttachedTo(bindable);
                bindable.SetBinding (ItemsTemplateProperty, ItemTemplate);
                bindable.SetBinding (ItemsSourceProperty, ItemsSource);
            }
        }
    

    and I use it this way:

        <StackLayout Orientation="Horizontal">
            <StackLayout.Behaviors>
                <local:ItemsSourceBehavior 
                    ItemsSource="{Binding WeatherPeriods}"
                    ItemTemplate="{Binding itemTemplate}" />
            </StackLayout.Behaviors>
        </StackLayout>
    

    with this BindingContext:

                BindingContext = new {
                    WeatherPeriods = new [] { "Foo", "Bar", "Baz", "Qux" },
                    itemTemplate = new DataTemplate (typeof(Label)) {Bindings = {
                        { Label.TextProperty, new Binding (".") }
                    }
                } };
    

    but wait, there's a better way to handle this, more in a coming post

  • StephaneDelcroixStephaneDelcroix Stephane Delcroix USInsider, Beta ✭✭✭✭

    In fact, there's no need to involve a Behavior here, it can all be done with some attached BindableProperties. It's better, simpler, cleaner:

        public static class ItemsSourcer
        {
            public static readonly BindableProperty ItemsSourceProperty = 
                BindableProperty.CreateAttached ("ItemsSource", typeof(IEnumerable), typeof(ItemsSourcer), default(IEnumerable), propertyChanged: OnItemsSourceChanged);
    
            public static IEnumerable GetItemsSource (BindableObject bindable)
            {
                return (IEnumerable)bindable.GetValue (ItemsSourceProperty);
            }
    
            public static void SetItemsSource (BindableObject bindable, IEnumerable value)
            {
                bindable.SetValue (ItemsSourceProperty, value);
            }
    
            static void OnItemsSourceChanged (BindableObject bindable, object oldValue, object newValue)
            {
                Repopulate (bindable);
            }
    
            public static readonly BindableProperty ItemTemplateProperty = 
                BindableProperty.CreateAttached ("ItemsSource", typeof(DataTemplate), typeof(ItemsSourcer), default(DataTemplate), propertyChanged: OnItemTemplateChanged);
    
            public static DataTemplate GetItemTemplate (BindableObject bindable)
            {
                return (DataTemplate)bindable.GetValue (ItemTemplateProperty);
            }
    
            public static void SetItemTemplate (BindableObject bindable, DataTemplate value)
            {
                bindable.SetValue (ItemTemplateProperty, value);
            }
    
            static void OnItemTemplateChanged (BindableObject bindable, object oldValue, object newValue)
            {
                Repopulate (bindable);
            }
    
            static void Repopulate (BindableObject bindable)
            {
                var layout = bindable as Layout<View>;
                if (layout == null)
                    return;
                layout.Children.Clear ();
    
                var itemsSource = layout.GetValue (ItemsSourceProperty) as IEnumerable;
                var template = layout.GetValue (ItemTemplateProperty) as DataTemplate;
    
                if (itemsSource == null || template == null)
                    return;
    
                foreach (var item in itemsSource) {
                    var content = template.CreateContent () as View;
                    if (content == null)
                        continue;
                    content.BindingContext = item;
                    layout.Children.Add (content);
                }
            }
        }
    

    and it's used this way:

        <StackLayout Orientation="Horizontal"
            local:ItemsSourcer.ItemsSource="{Binding WeatherPeriods}"
            local:ItemsSourcer.ItemTemplate="{StaticResource itemTemplate}" />
    
    
  • TroyWillmotTroyWillmot Troy Willmot NZMember, University

    Thanks Stephane. Xamarin have replied saying the same as you (by design, for performance and share-ability reasons).

    The samples you provided are very helpful too.

  • jonathanyatesjonathanyates jonathan yates GBMember ✭✭✭

    Thanks Stephane. I see in your second example you are reverting to using attached properties, which in WPF is the 'old way' of attaching behaviors to an ui element. In WPF this was replaced with Behavior which is a much simpler and cleaner approach and allows you to define DependencyProperties which can be bound to the DataContext in Xaml. I am expecting the Xamarin.Forms Behavior to work in the same way, but you say it is meant to be shared and BindableProperties do not work as expected because the behavior BindingContext does not get set. Your second example seems to negate the use of Behavior altogether, in favour of the 'older' attached property technique. Please could you provide some examples of how you would use Behavior and how it is meant to be shared?

  • TroyWillmotTroyWillmot Troy Willmot NZMember, University

    I agree with Jonathan, some samples or details of when to use a Xamarin behaviour (since it doesn't appear to be the same as other xaml frameworks) would be greatly appreciated. Thanks.

  • jonathanyatesjonathanyates jonathan yates GBMember ✭✭✭

    Stephane, you also mention not to handle Behavior as if it was a BindableObject, but Behavior IS a BinableObject therefore you would expect to to behave like one. i.e. Taken from the Xamarin.Forms BindableObject documentation it states:

    "The Xamarin.Forms.BindableObject class provides a data storage mechanism that enables the application developer to synchronize data between objects in response to changes, for example, between the View and View Model in the MVVM design pattern. All of the visual elements in the Xamarin.Forms namespace inherit from Xamarin.Forms.BindableObject class, so they can all be used to bind the data behind their user interface elements to View Models that are supplied by the application developer."

    This is not the case with Behavior. I'd also say the same thing for Trigger which is also a BindableObject. In fact I don't really follow you reuse argument because BindableProperties are staticly shared anyway and I would expect the Behavior to be able to store the state for the specfic element it is associate with. Styles in the other hand I would expect to be shared across ui elements and I see that Style is not a BindableObject, which makes sense.

  • DanielMayDanielMay Daniel May GBMember

    It's worth noting that the (unofficial, pre-1.3) Xamarin.Forms.Behaviors nuget package appears to implement Behavior<T> in the same vein as WPF & SL. Looks like it fully supports T AssociatedObject - missing from Xamarin's Behavior<T>.

    I'm also confused as to why, with Xamarin's implementation, Behaviors are no longer attached on a per-control basis - instead now, the same instance of a Behavior can exist at multiple points in the tree.

    It looks like @JesseLiberty was planning on covering Forms Behaviors in his Xamarin blog series (see end of post: "the next posting will move on to the third cool feature in 1.3: behaviors.") but it doesn't appear to have been posted yet. :neutral: Hopefully soon!

  • jonathanyatesjonathanyates jonathan yates GBMember ✭✭✭

    That's really interesting. I'm using 1.3.1 but it doesn't apear to have T AssociatedObject like you say. Perhaps it's in the latest 1.3.3, I'll have to check. If this is the case and Behaviors are to be used the same as those in WPF/SL then I don't really understand the advise given above which is contary to this.

    It makes sense for behaviors to be per-control so they can bind to a VM or other resources and have this state manitained per-instance for the control they are providing the Behavior. I also noticed that Jesse hasn't yet posted on Behaviors. Perhaps he came across the same issue. I think some clear guidence on Behaviors is needed and some clarification on their shared usage, which to me doesn't really make any sense.

  • jonathanyatesjonathanyates jonathan yates GBMember ✭✭✭

    Daniel, sorry I didn't realised you were actually referring to the seperate Xamarin.Form.Behaviors package, which has always mirrored that of the WPF/SL and in my opinion is a much better implementation that that provided in Xamarin.Forms 1.3. I was using this prior to the introduction of Behavior in Xamarin.Forms 1.3 and expected the inclusion of it in 1.3 to be consistent, but it doesn't apear to be that way unfortunately.

  • DanielMayDanielMay Daniel May GBMember

    No problem Jonathan. Just realised you're the chap behind adventuresinxamarinforms.com - nice work so far! You and I have very similar backgrounds. :smiley:

    The good news is that you should still be able to use the unofficial X.F.B NuGet package with your 1.3.x project - just make sure you're referencing the correct Behavior in your code.

    It would be interesting to see a performance comparison between unofficial and official Behaviors - it's quite possible that this shared Behavior approach is significantly leaner than the unofficial XFB WPF-esque AssociatedObject approach.

  • jonathanyatesjonathanyates jonathan yates GBMember ✭✭✭

    Daniel, Thanks. Seems a bit add though that the recommendation is to use Attached Properties instead of using a Behavior. In many cases when I create a Behavior it requires some BindableProperties (DependencyProperties) and I would expect them to work because Behavior is a BindableObject.

  • TroyWillmotTroyWillmot Troy Willmot NZMember, University

    So we still don't have a good answer right? Use the old, unofficial behaviours library is an option but not really an answer. What is the use case for the design of the Xamarin behaviours? They seem mostly useless without bindable properties. I have not yet attempted to create a behaviour that didn't have a bindable property.

  • jonathanyatesjonathanyates jonathan yates GBMember ✭✭✭

    I agree, behaviors are very limited without bindable properties. I think the best solution for now is to apply my fix and set the BindingContext when the associated object binding context changes.

    Also I don't really follow the advice not to keep a reference to the associated object (_stackLayout in this case). It makes sense to do this, as with WPF Behaviors which have an AssociatedObject property. This would not cause an issue with reuse because the behavior is per instance of the ui element it is attached to and not a static shared class.

  • TroyWillmotTroyWillmot Troy Willmot NZMember, University

    I think the problem is that it breaks if you apply the behaviour inside of a style or trigger. I suspect (though have not tested) that some sort of caching/reuse of the behaviour is implemented if you use it within a style or trigger - at which point the same instance of the behaviour is going to be linked to multiple views but it is only capable of keeping a reference to one, which will lead to 'weirdness'. This is why the binding context can't be set, and why you can't keep a reference to your stack layout - there might be more than one stack layout (or context) for a single behaviour instance.

    Unfortunately I don't see a solution. The two work-arounds provided by Stephane have issues of their own. The one where we don't use a behaviour at all has a few issues;

    1. You can't attach the same behaviour multiple times to a view. Imagine an EventToCommand behaviour, perhaps you want to attach it to both the Completed and GotFocus or KeyPress events etc. on the view and have each event run different commands. By using an attached property without a behaviour, there is only one command property on the view to set so you can't assign multiple events or commands.

    2. This is exactly the kind of thing behaviours are used for the MS XAML frameworks. If that's not appropriate here, what are the XF behaviours actually for? What use cases do they solve?

    3. Personally, I don't like the XAML syntax where we are setting properties that are about the behaviour (and prefixed with the behaviour name & namespace) on the node for the view.

    The earlier example that was still inherited from behaviour but did awkward mapping of the bindings also has issues;

    1. Doesn't allow for the bindings to change (Stephane notes this too), so we have bindable properties that really aren't bound (or at least behave differently to other bindable properties). In reality this probably isn't a problem for my use cases, but it feels like it might be a trap for future devs.

    2. This example, as written, will fail if one of the bindable properties isn't bound. Again with the EventToCommand example, you might have a CommandParameter property which isn't required. If no binding is set in the xaml for this property then the code in the OnAttach method will throw an ArgumentNullException. Ok, we can add a null check to avoid this, but then we're back to problem 1 where the property isn't really bound and doesn't update if the bound value changes. Incosistent!

    3. It seems ugly and confusing to read, with all the binding remapping. No offense to Stephane, but even he suggested the second solution was cleaner and simpler.

    Using the Xamarin behaviours as is doesn't allow bindable properties at all. If we apply the solution both you and I came up with them it works, until we use them in a style or trigger (I suspect).

    So really, it seems they are useless. There might be a set of use cases where they aren't, but I am struggling to think of even one. The lack of our response to the question of what these are good for seems to indicate no one else knows either?

    The 3rd party library for Behaviours actually seems like a better option at this point, but I was keen to drop the additional dependency from my solutions and was hoping for something official/perhaps better from Xamarin. I find this to be very disappointing.

    It's almost like they tried to solve an inefficiency/performance issue, but in doing so broke the usefulness of the tool. However I'm loathe to actually make that assertion since the Xamarin guys probably know far more about this than I do. Some examples from them on what XF behaviours are good for and how to solve our issues (using behaviours or something else) would be fantastic. I think what we really lack is understanding.

  • TroyWillmotTroyWillmot Troy Willmot NZMember, University

    Sorry, just to clarify... when you say;

    This would not cause an issue with reuse because the behavior is per instance of the ui element it is attached to and not a static shared class.

    I think what Xamarin are saying is, that is not true if the behaviour is used within a style or trigger - there isn't one instance per view in that case. Though that is kind of reading between the lines.

  • jonathanyatesjonathanyates jonathan yates GBMember ✭✭✭

    Troy,

    Could you provide an example of how you would apply a Behavior within a Style or trigger. I think these cases are quite rare anyway and I tried to have a go at this but wasn't sure what you meant. It doesn't look possible to add behaviors by setting the behavior property on a control in a style cos Behaviors is readonly anyway. How would you achieve this? In my mind this isn't really an issue because you wouldn't do this anyway.

  • TroyWillmotTroyWillmot Troy Willmot NZMember, University

    Sadly, no because I've never done it and don't need to, so like you I'm not really sure how. Right now it's not a use case I support/care about. The reason I raise it is because the Bugzilla bug I filed has a comment on it from the XF team saying triggers and styles are specifically places where this is an issue (and because you were assuming 1 behaviour instance to 1 associated object);

    Jason Smith 2015-02-05 01:44:30 NZDT
    The BindingContext is not set so the behavior can be applied to multiple items
    in the UI tree without the need to be cloned (which applies GC pressure on
    mobile among other bad things) and to enable behaviors to be easily embedded in
    styles.

    As you can see, they specifically say with a style they might apply the behaviour to multiple UI items without cloning it (presumably a single instance). It's not entirely clear when this happens, but they also mention styles in the same breath so I'm reading between the lines.

    Like you, I am at least for for now, sticking with the original solution of managing the binding contexts myself. It doesn't cause me any issues for my use cases. I've invented a base class to do this and track the associated object. It should, I hope, also throw a nice explanatory exception if the behaviour ever does get reused (rather than just providing weird unexplained behaviour). I haven't tested that though.

    I've made a gist of it in case it's useful to anyone else;

    https://gist.github.com/Yortw/f4b1220296de0a1d53ce

  • TroyWillmotTroyWillmot Troy Willmot NZMember, University

    Note also that I asked in the bug report what the XAML syntax was for applying the same instance multiple times, but received no response.

  • jonathanyatesjonathanyates jonathan yates GBMember ✭✭✭

    I see there is a new article on XF Behaviors here http://forums.xamarin.com/discussion/32910/

    Unfortunately it does not address this issue.

    Please can the XF team respond with some clarification and examples on behavior reuse and usage in styles?

  • jonathanyatesjonathanyates jonathan yates GBMember ✭✭✭

    And examples of behaviors with BindableProperties which can be bound to the BindingContext (ViewModel), which is the most likely scenario in my experience.

  • jonathanyatesjonathanyates jonathan yates GBMember ✭✭✭
    edited February 2015

    Given that there are no examples forthcoming using behaviors with styles I thought I'd try and use the above modified Behavior provided by Stephane with Styles.

    I applied the style like this.

    <ContentPage
        xmlns="http://xamarin.com/schemas/2014/forms"
        xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
        xmlns:b="clr-namespace:BehaviorSpike;assembly=BehaviorSpike"
        x:Class="BehaviorSpike.MainPage" Padding="0,40,0,0">
    
      <ContentPage.BindingContext>
        <b:ViewModel>
          <b:ViewModel.Items>
            <x:String>one</x:String>
            <x:String>two</x:String>
            <x:String>three</x:String>
          </b:ViewModel.Items>
        </b:ViewModel>
      </ContentPage.BindingContext>
    
      <ContentPage.Resources>
        <ResourceDictionary>
          <Style x:Key="StackLayoutStyle" TargetType="StackLayout">
            <Style.Behaviors>
              <b:ItemsSourceBehavior ItemsSource="{Binding Items}">
                <b:ItemsSourceBehavior.ItemTemplate>
                  <DataTemplate x:Key="ItemTemplate">
                    <Label Text="{Binding}" />
                  </DataTemplate>
                </b:ItemsSourceBehavior.ItemTemplate>
              </b:ItemsSourceBehavior>
            </Style.Behaviors>
          </Style>
        </ResourceDictionary>
      </ContentPage.Resources>
    
      <ContentPage.Content>
        <StackLayout>
          <StackLayout Orientation="Horizontal" Style="{StaticResource StackLayoutStyle}" />
          <StackLayout Orientation="Horizontal" Style="{StaticResource StackLayoutStyle}" />
        </StackLayout>
      </ContentPage.Content>
    
    </ContentPage>
    

    The ViewModel in this case is very simple.

        public class ViewModel : BindableObject
        {
            public ViewModel()
            {
                Items = new List<string>();
            }
    
            public List<string> Items { get; set; }
        }
    

    and the behavior taken from Stephane's example is as follows:

        public class ItemsSourceBehavior : Behavior<StackLayout>
        {
            public BindingBase ItemsSource { get; set; }
    
            public DataTemplate ItemTemplate { get; set; }
    
            static readonly BindableProperty ItemsSourceProperty =
                BindableProperty.CreateAttached("ItemsSource", typeof(IEnumerable), typeof(ItemsSourceBehavior), default(IEnumerable),
                    propertyChanged: ItemsSourceChanged);
    
            static readonly BindableProperty ItemsTemplateProperty =
                BindableProperty.CreateAttached("ItemTemplate", typeof(DataTemplate), typeof(ItemsSourceBehavior), default(DataTemplate));
    
            private static void ItemsSourceChanged(BindableObject bindable, object oldValue, object newValue)
            {
                ItemsSourceChanged((StackLayout)bindable, (IEnumerable)oldValue, (IEnumerable)newValue);
            }
    
            private static void ItemsSourceChanged(StackLayout stackLayout, IEnumerable oldValue, IEnumerable newValue)
            {
                stackLayout.Children.Clear();
    
                var template = stackLayout.GetValue(ItemsTemplateProperty) as DataTemplate;
                if (template == null)
                    return;
    
                foreach (var item in newValue)
                {
                    var content = (View)template.CreateContent();
                    content.BindingContext = item;
                    stackLayout.Children.Add(content);
                }
            }
    
            protected override void OnAttachedTo(StackLayout bindable)
            {
                base.OnAttachedTo(bindable);
    
                bindable.SetBinding(ItemsSourceProperty, ItemsSource);
                bindable.SetBinding(ItemsTemplateProperty, "ItemTemplate");
            }
        }
    

    When I run this I get the following exception:

    Unhandled Exception:
    System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.

    So doesn't seem to work with styles. Can someone from Xamarin help with this please?

  • jonathanyatesjonathanyates jonathan yates GBMember ✭✭✭

    Can anyone from Xamarin Team comment on this please?

  • TroyWillmotTroyWillmot Troy Willmot NZMember, University

    Can you check what the inner exception of the target invocation exception is? That usually has the real detail, and may indicate if the problem is in the XF framework or is something in the code we could adjust.

  • jonathanyatesjonathanyates jonathan yates GBMember ✭✭✭

    Ah yes Troy, forgot to post the inner exception, which is:

    InvalidBindingOperation: Binding instances can not be reused
    at Xamarin.Forms.BindingExpression.Apply (System.Object sourceObject, Xamarin.Forms.BindableObject target, Xamarin.Forms.BindableProperty property)

    Which suggests the BindingBase instance for the ItemsSource can not be shared.

    Please can someone from Xamarin Team comment on this?

  • hvaughanhvaughan hines vaughan USMember ✭✭✭

    @jonathanyates
    I know that on Xamarin's Behavior page they mention that you should not attach a behavior that carries state to a style. Could that be the issue here? Link

  • GattzGattz Mike Overwater USMember

    It would appear I have found a great thread full of people with knowledge on Behaviors :)
    Any chance one of you gentlemen has an idea what is going wrong in this case?
    http://forums.xamarin.com/discussion/comment/170023#Comment_170023
    Any help is most welcome since I have been stuck for quite a long time.

  • JesperJensenJesperJensen Jesper Jensen USMember

    I just want to thank everyone in this post.
    I ran into this issue with a Binding on my Behavior and this post both saved me a ton of time and gave me a working solution.

    Many thanks!

Sign In or Register to comment.