Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Again, I hope I am doing this PR correctly.
With the
datetime
mode, when you "set" the date and move to the time, the input value gets updated. If you then click Cancel, the changed date does not revert to the original one because the set on the date sets original to the new date (inonSetClick()
) so it has lost the original.Also, in my app, I needed to know when the user did click Set and did click Cancel (or blurred away) because I am using your picker in a custom composite field with 2 datetime pickers. and needed to take definitive action.
So, I have made some suggestions via this PR to make all that work. I left comments in the code (
QDatetimePicker.js
) which you will see to explain my thinking.For the issue of "undoing" the date even if the user has clicked Set on the date, I am listening for the
cancel
event in my app and reverting to my saved date property. This seems better than trying to come up with a way to do it within your datetime picker. And, I can imagine someone might want the current functionality. So, using acancel
event and letting the user handle the "undo" themselves seems like a better option.Thanks again for your work,
Murray