Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
When applying a behaviour to a view, the behaviour does not inherit the bindingcontext of the view, and the behaviour bindingcontext remains null. This means bindable properties on the behaviour do not work.
A work around is possible by manually subscribing to the view bindingcontextchanged event (inside the behaviour) and assigning the context in the event handler, but that should be unnecessary.
More details/examples can be found in this Xamarin Forms post;
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.
That's great feedback, thanks, and good reasons for it to work this way but it leaves me with two more questions;
1. How are we supposed to build a behaviour that uses data from bindings? (and why is Behaviour<T> derived from bindableobject if it will never has a binding context?). A really common behaviour to build (since there doesn't seem to be an implementation provided) is EventToCommand, which requires as a minimum a command object and probably a command parameter value as well. Both of these should come from bound properties. I guess we could use attached properties on the associated View and retrieve the values from there, but that means the property bindings in the xaml are declared in a different node than the behaviour itself which seems confusing, weird and ugly. Is there a pattern/solution here I'm missing? Behaviours using bound values seem to be very common.
2. I would love to apply only a single behaviour instance to multiple items to reduce memory/GC pressure, but I can't figure out the syntax to do that with xaml. All the sample code I've seen just does;
Which seems to be creating a behaviour instance in each view. What is the xaml syntax for reusing a single behaviour instance across multiple items?
Wait, seem to be some answers in the original forum post.
Thanks for your help guys.
Please at least include some info about this in the docs and remarks of the Behavior.
I still don't get it. I'm running into the same issue (along with more users according to google) and still don't see a solution. I'm trying to apply a behavior that should do something when a property in the viewmodel changes. Because the bindingcontext doesn't propagate, I don't see a way to do this. Is there any workaround?