When programmatically scrolling calendar, didSelectDate gets called.

[danielt1263]

I need a way to determine whether the calendar is scrolling because the user swiped it or because I changed it programmatically.

Note for example that when we programmatically scroll a UITableView, the scrollViewDidEndDecelerating doesn't get called also when programmatically selecting a cell in a table view, didSelectRowAtIndexPath doesn't get called.

However, when I programmatically scroll a calendar view by calling scrollToDate then didScrollToDateSegmentStartingWith:endingWithDate: does get called.

[patchthecode]

Looking into this. Will fix in some hours

[patchthecode]

Hey. I just added an upgrade to master branch of this repository, can you check it out and see if it works for you?

If all is well, then in will release a new cocoa pod version in a couple hours after testing.

[patchthecode]

After taking an update from Master branch, you can now call the function like this:

calendarView.scrollToDate(date, triggerScrollToDateDelegate: false)

Let me know if it works. And if it does, dont forget to leave a ★ Star rating here on github. Its needed to make this control # 1 :)

[danielt1263]

Thanks. This is exactly what I was looking for.

[danielt1263]

Hmm... I noticed that calendar(calendar, didScrollToDateSegmentStartingWith startDate, endingWithDate endDate) still gets called when the calendar is being constructed. In my book, that's a programatic change as well. I need a method that will only get called when the user initiates the scroll.

I'm trying to integrate the calendar with a unidirectional flow system and that's hard to do if I can't distinguish user input from system output. Thanks.

[patchthecode]

Ok looking into it.

[patchthecode]

For my project, the calendar didn't need to distinguish between programatic vs user change, so I never added the code to do this.

But What you say make sense. Calendar construction is a programatic change an not user initiated. I'll make this change in a bit. Since the project originally didn't need distinguish who initiated the change, if you find any other issues, let me know.

[danielt1263]

I'm happy to. Thanks for the great library.

[patchthecode]

Thanks man.
Btw i had one question and needed a suggestion from you.

When the calendar is just created, i call the didScoll delegate to inform the user on which month/day they are currently on. When the delegate is called, a developer will hook into the function and update any UILabels that have that shows which month they are currently on etc.

If i remove this feature, on calendar creation, then this would be problematic. I am still thinking of ideas ok, but do you have any suggestions that will make both you, and the other devs currently using this library happy?

[danielt1263]

IMHO, on calendar creation, the calendar should not be telling the client which month/day it is currently on. Instead the client should be telling the calendar what month/day to start on. I would make it an extra return value for the configureCalendar method. Make a precondition that currentDate must be <= startDate and < endDate.

Something like:
func configureCalendar(calendar: JTAppleCalendarView) -> (startDate: NSDate, currentDate: NSDate, endDate: NSDate, calendar: NSCalendar)

If you are worried about breaking changes, you could make a separate startingDate(calendar: JTAppleCalendarView) -> NSDate

[patchthecode]

Makes sense man. Thanks for the input. Working on it right now.

[patchthecode]

updated to version 3.0.0
Thanks for the help. If the issue is resolved you can close this one till the next time you bug me :)