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.
Created attachment 9669 [details]
The Scrolled event and the UITextView Changed, SelectionChanged, etc. events all use the same underlying Delegate property. Prior to the unified API the UITextView binding used the `new` keyword for the Scrolled event to ensure that you wouldn't get the UIScrollView's Scrolled event, which would overwrite the Delegate. The unified API removed the Scrolled event from the UITextView class, which means using it falls back to the UIScrollView class, and now you can't use both Scrolled and Changed/SelectionChanged/etc.
See the attached code example. Observe that only the Scrolled event fires for the text view, even though both Changed and SelectionChanged are also subscribed.
A better solution that the one used in the classic API would be to make the UIScrollView events virtual. Otherwise you could still run into this problem if the compile-time type of the text view object is UIScrollView. Consider this example:
private UITextView CreateTextView()
var textView = new UITextView();
textView.Changed += HandleChanged;
private void AddScrolledHandler(UIScrollView scrollView)
scrollView.Scrolled += HandleScrolled;
Even with the classic API approach of using the new keyword this would still break the Changed handler because it would end up using the UIScrollView's Scrolled event instead of the derived type. A virtual event would solve that. I suggest that all Delegate-based events in the bindings should use this approach.
Yes, we found out this case recently. If affects a few iOS API (a but more on the Mac). Work is under way to correct the binding generator so events can co-exists peacefully with subclasses.
Chris fixed this in the generator in maccore/master 9aab4bb4c49548f3b6bb6edf79b3554e4cc6db4d and you'll be able to subscribe to both events with the unified API.
QA: unit test added in 2885e2d9ffd237dbb9e5fe36c4e340eeb1a0117d