Sorry to pile on! Another couple of things...
I noticed a couple of issues in version 7.0.1 with incorrect dates when generateOutDates = .tillEndOfRow:
Here's a sample project which shows these two issues. Calendar is configured with startDate = May 1, 2016 and endDate = April 30, 2017 (a 1-year span). Everything looks okay when generateOutDates = .off, but not so okay when generateOutDates = .tillEndOfRow.
Also note when you change hasStrictBoundaries to true, even when generateOutDates = .off, the dates are misaligned - April 1, 2017 ends up as a Sunday, rather than a Saturday.
Here's a screenshot when generateOutDates = .tillEndOfRow, hasStrictBoundaries = false:

And here's a screenshot when generateOutDates = .off, hasStrictBoundaries = true

Thanks!. Add all the found issues in here.
I'll check em out after work
Ok i just took a look at it. This does not look like a bug.
I can explain this more to you when youre awake.
I think i'll do a video on this
issue explained. All is well.
Closing this issue.
I will add the enhance we spoke about.
cheers 🍻
Much appreciated for the chat today! For anyone looking at this thread in the future, basically, don't configure the calendar like this. :P Basically the problem was that generateInDates sets the initial offset of the columns, and generateOutDates runs for the end of _every_ month. So an infinite flow of dates with generateOutDates on results in those out dates getting generated twice (once for the end of month, and once again for the new month). This is primarily for horizontal-flowing calendars.
If you need an infinite vertical scroll of dates flowing into each other, set generateOutDates = .off. @patchthecode will consider an enhancement which lets you get out dates for the very last week of the calendar for visual consistency.
@UberJason added new feature request issue. -> https://github.com/patchthecode/JTAppleCalendar/issues/380
I'll work on this when i'm free again
@UberJason had one last question, was the reloading dates problem still happening?
Yes, I believe so. I'm working around it for now.
@UberJason alright then, i'll have a look
@UberJason
I have added your comment:
also just leaving this here for you for later...
I stepped through some of the code and see the problem (but not sure the best way to fix, so I'll just alert you to it).
In short, reloadData() is calling selectDates() only after its completion handler gets run.
my usage is this:
calendarView.reloadData() {
if self.calendarView.selectedDates.count > 0 {
// do stuff with the selected dates }
}
(couldn't get that formatted right but you get the idea -
I check the selectedDates in the reloadData() completion handler.)
I see under the hood that reloadData() calls selectDates(_:,triggerSelectionDelegate:,keepSelectionIfMultiSelectionAllowed:) and then the completionHandler.
The selectDates(...) function checks if functionIsUnsafeToRun, and if so, it adds itself to the end of the delayed execution queue.
Then the completionHandler runs. Then selectDates(...) is run again, and this time it's safe to run, so it does update the dates.
So in short, the calendar does EVENTUALLY restore selected dates, but not until after the completion handler, which is when my usage requires it.
I'm assuming that I'm not doing some unintended stuff - that the selected dates should be available by the time the completionHandler has run.
the part that i got lost on was this
Then selectDates(...) is run again
You meant to say selectedDates right?
And then you said run again. So my question is -> is this reload code done in the viewDidLoad() function?
No - I'm talking all about code internal to your calendar view. I did not mean selectedDates, I meant selectDates(...) is run again - by that I mean, selectDates(...) adds itself to the end of the delayed execution queue if functionIsUnsafeToRun, which means that after it finishes, it gets called again (it's basically recursion). Does that help?
@UberJason ok i understand. But can you tell me if you reloadData is called in your viewDidLoad?
or maybe you can tell me where in you code you call the reloadData function?
Thanks for all the help.
I'm calling reloadData on a button press from the user. For us it's a button that toggles the size of the calendar from 2 to 6 rows (with a corresponding increase in the calendar's height to match). On button press, I animate the calendar to alpha = 0, then animate the calendar height increase, then reloadData, and in the completion handler of reloadData, animate the calendar to alpha = 1.0.
Thank you. will look into this.
@UberJason when ever you get the chance, i wish you can upload a small zipped copy of the issue (with all your secret code removed). I am not able to reproduce it from my end. And I am not good at animation code, so i do not really know how to reproduce it :<
Cool. I'll try to get around to it on Monday - it was code in a work project. It's not a big deal in any case, since the dates do eventually get re-selected and I can just save the date locally before reloading the calendar!
@UberJason it may not be a big deal to you but.. i got many people using this. Dont stress too much, but if its possible, then i'd be grateful :]
Hey man, I've updated my old CalendarBug project to show the problem with selected dates. See the project here: https://github.com/UberJason/CalendarBug
Note the print statements, initially in viewDidAppear I show the calendarView.selectedDates array correctly contains one selected date. Then when you tap "Toggle" to do the calendar animation, in the completion handler of reloadData, you see the selectedDates array is empty. Then after a short while (I chose 1 second but it is probably shorter), the selectedDates array is correctly populated again.
@UberJason thanks! looking into it
Here is the updated Library I hope i didnt break anything.
Still testing. Will include in next release if no issues found.
Library Changes:
reloadData(with anchorDate) has been removed.swift
calendarView.reloadData {[weak self]
self.calendarView.scrollToDate(myDate)
}
Oh yeah, I actually only threw anchorDate in there at one point while I was playing with it, and forgot to remove. I'm not doing anything with it myself either.