CalBox is changing current date when navigating next/prev month, but not highlighting it.

[slavap]

Example: user selected 11/29, it's highlighted. Then pressed next month. Selected date changed automatically to 11/30 and December is shown (datebox('getTheDate') returns 11/30), but this new selected date is not highlighted, which looks confusing for user. Inline mode.

UPDATE: displayed date in container remains unchanged (selected by user), but datebox('getTheDate') returns chaotic results when navigating by prev/next months. It should return date selected by user all the time and restore highlighting when returned to the month started from.

[jtsage]

eww. ok, let me look a bit closer at this.

short version - it's because I jack with the internal date when you change months - it processes an offset. What I will probably have to do is store the "currently selected" date somewhere safe when an offset operation happens on the calendar, and return that for getTheDate - the challenge is going to be in making sure that getTheDate always gets it right. Same for returning the selection when navigating back.

I'll need to think this through a bit more - no idea what my tomorrow looks like, but fair warning, I've a bit of time off from work this week, and I'm planning on a run to the great white north for turkey and football :)

[slavap]

Thanks! Happy thanksgiving, I know it will be a very short work week for any person in the US :-)

[jtsage]

So, I just pushed a possible fix. I built only the -latest branch. I'm quite sure this breaks something, somewhere.

But, the behavior now is: opening a "blank" calendar selects today. Opening with a date selects that date.

Navigating months (with either the buttons or the pick list) will "save" the selected date. getTheDate will return the saved date. Obviously, clicking on a new date will discard the saved date.

Navigating back to the month with the selected date will now show that date still selected (fwiw, this always did work - unless of course you choose a date greater than the 28th (heh)).

[slavap]

I've tested these changes. It mostly works, there are some issues:

1. Change event is broken. If I select dates withing a month - it works. Then I switch to next month and select new date. Change event occurs, but datebox('getTheDate') returns previous date, not new one (though new date is highlighted successfully and input value is changed correctly). If I click one more time to the same new date, change event occurs once again and this time with correct value returned by getTheDate.
2. Also it would be nice to have new date returned by getTheDate during formatting calFormatter call.
3. It would be nice to have additional event like displayDateIsChanged, because some extended information may need to be hidden or changed when user is navigating to the different month and selected date is not present on the screen anymore.

I don't see any fatal errors with your changes, though additional testing is needed before populating these changes into 1.4.5 branch. Thanks!

[jtsage]

2.) can you explain this better, I don't follow (what does happen / what should? )

[jtsage]

1.) I was unsetting the backup date too late for the offset event - this should be fixed.

3.) how about "displayChange" (a little shorter). - until I run the build for 1.4.5 again, you can take a look at the doc here: https://github.com/jtsage/jquery-mobile-datebox/blob/master/docs/api/displayChange.md

Tested slightly, but at this point, I suspect what you are working on is a more robust test. pushed the build to -latest.

[slavap]

Ok, first the explanation for 2.) What I meant that call datebox('getTheDate') returned incorrect/"old" date when called from inside attached calFormatter function. It's fixed now.

ISSUE1: displayChange is not raised when I'm changing month from the combobox picker. ISSUE2: If selected date is still visible/shown on next/prev month view, it's not highlighted (example: Nov 30 is selected, switch to next month December, it's still on screen but not highlighted).

Rest of functionality is working fine, but there is a minor problem with handlers execution order. I have the following handlers attached: onChange, calFormatter, displayChange. Current execution order is:

1. calFormatter
2. onChange OR displayChange IMO it should be opposite, i.e. calFormatter should be the last one called, after change events. Otherwise (if you think exec.order is correct), additional helper method is needed: isDateShown(Date d) to have an ability to check from inside displayChange handler if selectedDate is still visible to user (Nov 30 is shown on December view).

Looks like this issue is very close to resolution, thank you!

[jtsage]

1.) indeed. forgot that use case. I can fix shortly.

2.) hmm. I don't think I've ever highlighted next/prev dates when not "current" - but I suppose I probably could. Added to the list.

As to order - here's what should be happening - however, it's async (sort of) -

• click +/- button (sets "backup" date, if not already set)
• _offset() fires which triggers events (and changes "real" date)
  • "offset" and
  • "displayChange"
• then refresh() is called (internally) and on that run through
• calFormatter() fires (per date).

Now, checking if the selected date is visible is pretty easy - I can expose a method to just check if w{idget}.calBackDate is not false - datebox('dateVisible') comes to mind (bool) - and maybe arg.dateVisible for calFormatter?

[slavap]

Yes, datebox('dateVisible') is fine. arg.dateVisible for calFormatter is useful as well if it's not affect performance. Also arg.selectedDateVisible could be useful in displayChange.

[jtsage]

ISSUE 1 - picklist not firing displayChange - it does now, soon as I push changes.

[jtsage]

ISSUE 2 - gonna open a new issue for this one. Just for book keeping. (highlight next/prev month date)

[jtsage]

dateVisible just got a lot harder. reporting if calBackDate is set is simple - but it's not the whole story. It tells us if the "selected" date is in the visible month. but not if it is shown on the calendar - i.e. the issue of end/start of month dates.

At any rate, I have a solution - but I can't add it to dislayChange - that event happens far too soon. (the calculation for if the date is visible has to happen right after we generate the visible calendar (well, the guts anyway) - then i just check against the start and end dates shown ( while respecting calOnlyMonth option).

Fwiw, there is a 'postrefresh' event which runs after all this crap, dunno if it helps or not...

[slavap]

I've tested the latest version. It's almost finished. And looks like dateVisible in calFormatter is enough (no need to have it in displayChange, at least in my scenario).

ISSUE: displayChange is not always firing. Test case:

1. select Nov 30 and change to December with plus button - event fired.
2. Then switch back to November with minus button - event is NOT fired.
3. Press minus button again to go to October - event fired.
4. Press plus button to go back to November - event is NOT fired.

Also don't forget to update documentation for displayChange. thisChange parameter can have 'p' value (picker) and thisChangeAmount is null in that case.

I think after fixing it's ready to be populated into 1.4.5 branch. Thank you!

[jtsage]

Correct, that is the behavior of displayChange. Right now, it only fires if the display Date is not on the screen. (or, more accurately, if calBackDate is set internally, which means the selected date is not in the month displayed).

I can of course tell it to fire whenever the display is changed, but how would you like selectedDate vs shownDate handled? (they are sort of identical, but in the case above, selectedDate === false. I can "fix" it for the event, but is that "false" more useful? dunno.)

And good catch on the documentation, already forgot I did that (as you likely noticed from the entire rest of the project, my documentation skills are poor at best :) )

[slavap]

Ok, so it's working differently from what I thought. I think example should be added to the documentation. It's "real" visibility vs "logical" one. Nov 30 is visible on December, but does not belong to that month. So displayChange is fired when selected date is not from displayed month, even if it's visible to user. That's OK behavior, just document it.

Please deploy to 1.4.5, looks like everything is OK now. If something fails under additional testing I will open new issues.

[jtsage]

1.4.5 re-deployed as well.

[jtsage]

Reopening for v5.0.0

[jtsage]

Re-closing, opened a couple new issues to make sure all of this made it in.