Jtapplecalendar: incorrect information reported by cellState in the didSelect delegate method

[boborbt]

For context here is the current month visualised by the calendar:

and here is a screenshot of inspecting cellState in the didSelect delegate method (btw Marzo si March in Italian):

as you can see the cellState reports that the first of april is a 'thisMonth' even though it is not. The same goes if I select dates even beyond in the feature (even when they are not among the dates displayed by the calendar view).

[boborbt]

By the way: is there any way to make the shouldSelectDate be called even for programmatically generated selections? Alternatively: there is an easy way to determine if a given date is in the current month outside a delegate method?

Rationale: I would keep the logic necessary to decide if a selection should occur in a single place. Since this logic relies on whether the selection is in the current month, I can either keep it in the shouldSelect delegate method (which can access that information using cellState) or move it into a separate method that will need to determine if the date is in the current month or not...

This question is marginally relevant to this issue since answering that would make the processing I'm currently doing in didSelect that causes the problem no longer necessary.

[patchthecode]

OK. Maybe the thisMonth concept is confusing.

cells have different descriptions depending on the month that they belong to:

If you physically touch the grayed out months 1 or 2:

These 2 dates here a considered to be the followingMonthWithinBoundary

Programatic selections however, always select the real month's date.
Therefore, if you programmatically selected the 1st of April or programitically select anydate, then the cellState will always be thisMonth.

ThisMonth is only a description. It basically says this -> the cell you have just selected is not a followingMonth cell, and it is not a previousMonth cell. It is a ThisMonth cell.

Maybe i should rename ThisMonth to be called currentMonth to make it less confusing?

[patchthecode]

is there any way to make the shouldSelectDate be called even for programmatically generated selections?

I can add this feature.

[patchthecode]

there is an easy way to determine if a given date is in the current month outside a delegate method?

Yes, I have several methods you can check out

1. public func cellStatus(for date: Date) -> CellState
2. public func cellStatus(at point: CGPoint) -> CellState?
3. public func cellStatusForDate(at row: Int, column: Int) -> CellState?

[boborbt]

Hi @patchthecode, thanks for your answers. I think I got the meaning of thisMonth correct, my confusion was about the fact that I assumed that the cell was the displayed cell, not the one in the next month. I think the name is perfectly fine and when the user taps cells they work as expected. I guess I am making a mistake related to the one I already did few weeks ago when you helped me out another problem, but it really itches me the fact that the meaning of stateCell is different when the methods are invoked by result of a programmatic call instead of a user event.

If I can suggest a way out of this confusion, perhaps it may help to make this difference between "real" date cells and "in/out" cells explicit. For instance the method may always receive the "real" cell and nullable property may report a reference to the in/out cell if applicable. Does it make sense?

Anyhow, thanks again for your awesome support, your answers above totally solve my particular problem.

[patchthecode]

it really itches me the fact that the meaning of stateCell is different when the methods are invoked by result of a programmatic call instead of a user event.

Ah. I think I know what you are thinking.

I guess that because your screen has full month of cells displayed,
you therefore think that selecting the 1st should select the grayed out April 1st cell (or at least return the grayed out April 1st cell in your didSelect delegate).

But here is the thing,
on your app you have a full month of cells displayed.
But it could be that on someone else's app, the have 1 and a half months displayed on the screen. Or 2 months displayed or 3... etc.

you can have more than one month displayed on the screen by changing the itemSize property.

Try this and see for your self; put this in your viewDidLoad(): calendarView.itemSize = 25

Now if both the grayed out date April 1st and the real April 1st is on the screen at the same time, then what should the cellState be? should it be .thisMonth or should it be followingMonthWithinBoundary ?

Therefore I made the library always select the .thisMonth dateCell. Whether or not is it visible on the screen. This was the reasoning behind my decision.

The visibility or the cell does not determine if it should be selected or not.
Programmatic selections always select the real date.

[boborbt]

Hi. Thanks for the answer, this makes a lot of sense. How, then, I determine if advancing the selection by 1 day will make it to "overflow" in the greyed out cells?

[boborbt]

Ok. never mind. I see there is a method "visibleDates" which returns me the set of outdates (I can then see if a date is included in them thus solving my problem).

Thanks again for your support.

[patchthecode]

youre welcome. 🍻
And that is exactly right.
This was the reason for the visibleDates function