Re: [MonoTouch] How do you actually listen to an UIScrollView scrolling

2014-01-03 Thread victoria
Ah, I was afraid of that. Really, I have to say, it's not much of an API
design when there are two ways of doing things and they silently break and
cancel each other out like this. We'll consider our options but as suspected
it'll probably not be possible to support both then.

Thanks Nic!

/ V



--
View this message in context: 
http://monotouch.2284126.n4.nabble.com/How-do-you-actually-listen-to-an-UIScrollView-scrolling-tp4658518p4658524.html
Sent from the MonoTouch mailing list archive at Nabble.com.
___
MonoTouch mailing list
MonoTouch@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/monotouch


Re: [MonoTouch] How do you actually listen to an UIScrollView scrolling

2014-01-02 Thread Nic Wise
As far as I know, you dont.

X.iOS has alway followed the following model:

1. you make a new object (UIScrollView on your case). It makes its own
UIScrollViewDelegate in the background, which calls the .Scrolled
events (and all the others)
2. you assign the delegate. This clears (or rather, replaces) any
events. They are still there, they just dont ever get called.

I don't think there is a way to go back from 2 to 1. Or a way to
detect which one you are in. Maybe check to see if .delegate is null
(or a specific class?) which would mean you are using the event model?






On Fri, Jan 3, 2014 at 4:52 AM, victoria iminurb...@hotmail.com wrote:
 Hi!

 I'm working with someone developing a pretty neat component, that might be
 submitted to the Xamarin component store later (or not, it's not entirely up
 to me). Without going into specifics, the end user will implement the
 component together with an existing UIScrollView, where it will listen to
 its scroll event. That's easy enough right? Well, not quite.

 In a perfect world the component would work like this:

   var target = new SomeUIScrollView();
   var component = new Component(target);

 and in the constructor we'd simply do

   target.Scrolled += magic(this, EventArgs.Empty);


 However... the above doesn't work if the UIScrollView is using an
 UIScrollViewDelegate. So, next idea was to do

   class Component : UIScrollViewDelegate
   {
 public override void Scrolled(UIScrollView scrollView)
 {
   magic(this, EventArgs.Empty);
 }
...

 and then the user would have to use or inherit from Component as their
 UIScrollViewDelegate and make sure to call the base methods if they
 themselves would override Scrolled.

 However... the above doesn't work if the user is using the event syntax.


 Question: As a third party library, how do you support both methods? If it's
 not possible, should we go with the event syntax (which feels very .NET) or
 instead implement it as an UIScrollViewDelegate (which feels more iOS)?

  / V



 --
 View this message in context: 
 http://monotouch.2284126.n4.nabble.com/How-do-you-actually-listen-to-an-UIScrollView-scrolling-tp4658518.html
 Sent from the MonoTouch mailing list archive at Nabble.com.
 ___
 MonoTouch mailing list
 MonoTouch@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/monotouch



-- 
Nic Wise
t.  +64 21 676 418 | @fastchicken
b. http://www.fastchicken.co.nz/
___
MonoTouch mailing list
MonoTouch@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/monotouch