CalendarTextField empty date display

[CosMoss]

I'm using CalendarTextField in a Java 8 app and I've noticed what I think is a bug. 

In my app I set an initial date - that works fine.  If I 'pop' the calendar and select a different date everything works fine. 

But, if I "pop" the calendar and re-select the same day that was already chosen (the one I set initially), the displayed date (text field area of the control) is cleared - it removes the date that was there and just shows an empty field.  If I select the same date again (second time) the date re-appears.

Only seems to happen if the new date selection matches the existing date.  If I change the date from my initial date to a different date I can reproduce the problem.   Except for the initial setting of my date, I do not set the date in the app. I do read the date after it's changed and the value is correct - it's just the display that seems to be messed up.

Not a big problem, but wanted to see if you were aware of it.

[tbeernot]

Interesting, it is not a bug, it is the expected behavior, but maybe the behavior is not what a user feels is logical... For me it makes sense.

What you are describing is the way to set a null value without using the keyboard. If CalendarPicker is used stand alone there is no way of erasing the date (because there is no textfield to clear), so the behavior is that if a selected data is clicked, then it is unselected thus resulting no selected dates (which equals null).

When used in the popup of CalendarTextField it must be able to show "null", after all the textfield may be empty. So no dates selected correctly indicates "null", the question is: given a textfield with a date, how would you set that to null using the popup?

I decided to use the same behavior for both stand alone and popup.

Regards, Tom

--
You received this message because you are subscribed to the Google Groups "JFXtras Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jfxtras-user...@googlegroups.com.
To post to this group, send email to jfxtra...@googlegroups.com.
Visit this group at http://groups.google.com/group/jfxtras-users.
For more options, visit https://groups.google.com/d/optout.

[Jay Moss]

Interesting, that makes sense.  Offhand, I can't think of a better way to set a null value, especially if there's no text field visible.  

But, in my situation I never want a null value set for the field, in fact I'd prefer to specifically prohibit that.  So maybe the answer could be to add a boolean property "allow nulls" or some such - if true just keep the current behavior.  If false, keep the previously selected (re-selected) value.  That should work whether the text field is shown or not.

You received this message because you are subscribed to a topic in the Google Groups "JFXtras Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jfxtras-users/mtswO-JW9xE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jfxtras-user...@googlegroups.com.

[tbeernot]

CalendarPicker in fact already has such a "allowNull" property, which disabled the unselect behavior. The question is what this would mean in context of the CalendarTextField.

If CalendarTextField would have an allowNull set to false, what would happen if the user would clear the textfield? In order not to force any specific behavior (like inserting "today" or showing an error popup), I would handle an empty text field with "allowNull" set to false as a parse error and call the parseErrorCallback.

Tom

[Jay Moss]

That makes sense, if the your field requires a value and it doesn't get one it's an error.  I think behavior in that situation would be up to the app to deal with - the 'today' value might make sense in some cases, but I wouldn't expect the control to operate that way by default.

So, looking at the code (I have 8.0-r1) it looks like you have a TODO for this idea already.  

Is there a way to set the CalendarPicker allowNull property from the CalendarTextField?

-jay

[tbeernot]

No, there is not. It would require the property to be CSS stylable. But this change is minimal, so I can quite easily add that tonight. A property and an if; I can do that ;-)

Tom

[tbeernot]

Give it a try (r2-SNAPSHOT)

On 2014-5-14 16:23, Jay Moss wrote:

[Jay Moss]

What else do I need to change to use the 8.0-r2-SNAPSHOT version?  

I updated my pom to that version and rebuilt, but when I run it now it throws errors on startup with the CalendarTextField  (full stacktrace attached):

May 14, 2014 12:47:45 PM javafx.scene.control.Control impl_processCSS

SEVERE: The -fx-skin property has not been defined in CSS for CalendarTextField[id=checkInDateField, styleClass=CalendarTextField CalendarTextFieldSkin] and createDefaultSkin() returned null.

I didn't change any code or set the new property yet....

-jay

On Wednesday, May 14, 2014, tbeernot <tbee...@gmail.com> wrote:

Give it a try (r2-SNAPSHOT)


On 2014-5-14 16:23, Jay Moss wrote:

That makes sense, if the your field requires a value and it doesn't get one it's an error.  I think behavior in that situation would be up to the app to deal with - the 'today' value might make sense in some cases, but I wouldn't expect the control to operate that way by default.

So, looking at the code (I have 8.0-r1) it looks like you have a TODO for this idea already.  

Is there a way to set the CalendarPicker allowNull property from the CalendarTextField?

-jay

On Wednesday, May 14, 2014, tbeernot <tbee...@gmail.com> wrote:

CalendarPicker in fact already has such a "allowNull" property, which disabled the unselect behavior. The question is what this would mean in context of the CalendarTextField.

If CalendarTextField would have an allowNull set to false, what would happen if the user would clear the textfield? In order not to force any specific behavior (like inserting "today" or showing an error popup), I would handle an empty text field with "allowNull" set to false as a parse error and call the parseErrorCallback.

Tom



On 2014-5-14 15:55, Jay Moss wrote:

Interesting, that makes sense.  Offhand, I can't think of a better way to set a null value, especially if there's no text field visible.  

But, in my situation I never want a null value set for the field, in fact I'd prefer to specifically prohibit that.  So maybe the answer could be to add a boolean property "allow nulls" or some such - if true just keep the current behavior.  If false, keep the previously selected (re-selected) value.  That should work whether the text field is shown or not.

On Tuesday, May 13, 2014, tbeernot <tbee...@gmail.com> wrote:

Interesting, it is not a bug, it is the expected behavior, but maybe the behavior is not what a user feels is logical... For me it makes sense.

What you are describing is the way to set a null value without using the keyboard. If CalendarPicker is used stand alone there is no way of erasing the date (because there is no textfield to clear), so the behavior is that if a selected data is clicked, then it is unselected thus resulting no selected dates (which equals null).

When used in the popup of CalendarTextField it must be able to show "null", after all the textfield may be empty. So no dates selected correctly indicates "null", the question is: given a textfield with a date, how would you set that to null using the popup?

I decided to use the same behavior for both stand alone and popup.

Regards, Tom




On 2014-5-14 0:44, CosMoss wrote:

I'm using CalendarTextField in a Java 8 app and I've noticed what I think is a bug. 

In my app I set an initial date - that works fine.  If I 'pop' the calendar and selec

--

[tbeernot]

Hm, I made another addition: I added a text property, because it seemed weird to me that you could not get the actual text inside a textfield. And went about that a bit too quick. Sorry. Please get the latest snapshot (use -U in maven to force an update).

Tom

You received this message because you are subscribed to the Google Groups "JFXtras Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jfxtras-user...@googlegroups.com.

[Jay Moss]

Still getting the same error.  I set -u in my maven build and also whacked the org/jfxtras directory in my local repo just in case.  

My repo manager is showing the following upload info on the r2 snapshot file:

/org/jfxtras/jfxtras-labs/8.0-r2-SNAPSHOT/jfxtras-labs-8.0-r2-20140514.080310-68.jar

Size:

450.58 KB

Uploaded Date:

Wed May 14 2014 02:03:15 GMT-0600 (Mountain Standard Time)

Is there a line in one of the files I can check to see that I actually have the right version and my repo manager isn't caching it?

You received this message because you are subscribed to the Google Groups "JFXtras Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jfxtras-user...@googlegroups.com.
To post to this group, send email to jfxtra...@googlegroups.com.
Visit this group at http://groups.google.com/group/jfxtras-users.
For more options, visit https://groups.google.com/d/optout.

[tbeernot]

Capital U

[Jay Moss]

Sorry, didn't get that one:  Capital U  where/for what?

--

[tbeernot]

You need to use -U in Maven not -u, or --update-snapshots.

http://books.sonatype.com/mvnref-book/reference/running-sect-options.html

You received this message because you are subscribed to the Google Groups "JFXtras Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jfxtras-user...@googlegroups.com.

[Jay Moss]

I'm lazy, 'been building in eclipse: with Update Snapshots checked.  

I reran and retested again today from both the command line and eclipse.  No change: still have the "-fx-skin property has not been defined" errors.

[tbeernot]

All tests run without problems ATM, so it really should work if you have the correct version. You could delete it from your local .m2 repository to be sure it is downloaded.

That error is probably preceded by an exception... Can you find that?

Tom

[Jay Moss]

I'm not sure if the previous attachment worked (the full stacktrace was there), but here's the initial error:

May 14, 2014 12:47:44 PM javafx.scene.control.Control loadSkinClass

SEVERE: Failed to load skin 'jfxtras.internal.scene.control.skin.CalendarTextFieldSkin' for control CalendarTextField[id=checkInDateField, styleClass=CalendarTextField CalendarTextFieldSkin]

java.lang.RuntimeException: A bound value cannot be set.

at javafx.scene.control.TextInputControl$TextProperty.set(TextInputControl.java:1053)

at javafx.scene.control.TextInputControl.setText(TextInputControl.java:279)

at jfxtras.internal.scene.control.skin.CalendarTextFieldSkin.refreshValue(CalendarTextFieldSkin.java:114)

at jfxtras.internal.scene.control.skin.CalendarTextFieldSkin.construct(CalendarTextFieldSkin.java:100)

at jfxtras.internal.scene.control.skin.CalendarTextFieldSkin.<init>(CalendarTextFieldSkin.java:86)

at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

...

May 14, 2014 12:47:45 PM javafx.scene.control.Control impl_processCSS

SEVERE: The -fx-skin property has not been defined in CSS for CalendarTextField[id=checkInDateField, styleClass=CalendarTextField CalendarTextFieldSkin] and createDefaultSkin() returned null.

...

[tbeernot]

Yes. That is the error you get because I had a binding in the wrong direction. Was solved yesterday, so you have the wrong version of the jar. I've just now re-released 8.0-r2-SNAPSHOT to make very sure the correct version is in the repo.

Tom

You received this message because you are subscribed to the Google Groups "JFXtras Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jfxtras-user...@googlegroups.com.

[Jay Moss]

Ok, progress (that worked: I checked my repo manager and I did pick up a new version with today's date).

The app starts cleanly now.  But, when I click on the calendar icon  (I've re-skinned the image via my own JFXtrasCalendar.css)  I get the following error:

Exception in thread "JavaFX Application Thread" java.lang.NullPointerException

at jfxtras.internal.scene.control.skin.CalendarTextFieldSkin.showPopup(CalendarTextFieldSkin.java:479)

at jfxtras.internal.scene.control.skin.CalendarTextFieldSkin.lambda$createNodes$10(CalendarTextFieldSkin.java:224)

at jfxtras.internal.scene.control.skin.CalendarTextFieldSkin$$Lambda$12/676785.handle(Unknown Source)

at com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:86)

...

I don't know if I mentioned it or if it matters, but my app is all FXML.

jay

You received this message because you are subscribed to the Google Groups "JFXtras Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jfxtras-user...@googlegroups.com.
To post to this group, send email to jfxtra...@googlegroups.com.
Visit this group at http://groups.google.com/group/jfxtras-users.
For more options, visit https://groups.google.com/d/optout.

[tbeernot]

line 224 is the event handling of the click, it calls popup

line 479 is the actual showing of the popup. It can only cause an NPE if either the popup is null, but there is an if right before creating the popup, or the textfield is null (and that is not the case since it is shown). Can you create a small example that reproduces this?

Tom

[Jay Moss]

Sure, try the attached (it's a very hacked up zipped maven project - eclipse project format, has all files).

Let me know the best way to get it to you if attachments don't work.

[tbeernot]

Reproducable! Thanks! It was a sequence thingy, uploaded a new version.

Tom

You received this message because you are subscribed to the Google Groups "JFXtras Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jfxtras-user...@googlegroups.com.

[Jay Moss]

Could you re-release it, my repo manager is stuck on yesterdays version and won't let me delete it from the cache.

You received this message because you are subscribed to the Google Groups "JFXtras Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jfxtras-user...@googlegroups.com.
To post to this group, send email to jfxtra...@googlegroups.com.
Visit this group at http://groups.google.com/group/jfxtras-users.
For more options, visit https://groups.google.com/d/optout.

[tbeernot]

done

[Jay Moss]

Sorry, it took quite a while before I picked up the new version (damn nexus).  

Without the allowNull property set, it works fine now - clicking on the currently selected day clears the field (same a before).

But, when I set allowNull to false, clicking on the same day throws an error (and clears the field):

java.lang.IllegalArgumentException: Empty string would result in null and that is not allowed

at jfxtras.internal.scene.control.skin.CalendarTextFieldSkin.parse(CalendarTextFieldSkin.java:297)

at jfxtras.internal.scene.control.skin.CalendarTextFieldSkin.lambda$construct$9(CalendarTextFieldSkin.java:101)

With allowNull=true, I don't think it should clear the text field - if my control is don't allow nulls, then nothing I do in the control should set the text field to null - at least that's what what I'd like to see.   If allowNull is true then clicking on the same day shouldn't change anything.

--

[tbeernot]

Agree. Something for tomorrow morning.

Tom

You received this message because you are subscribed to the Google Groups "JFXtras Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jfxtras-user...@googlegroups.com.

[tbeernot]

This is why one shouldn't make changes while working on other things. I know better. So it should be working as expected now, and I've added a bunch of unit test to make sure it stays that way.

New build is out there.

Tom


On 2014-5-16 22:14, Jay Moss wrote:

[Jay Moss]

Tom,

Almost there.  With setAllowNull() to false, the control lets me select the same date and keeps the date in the text field, but the calendar pop-up doesn't hide like it would if I selected a different date.  If I click elsewhere in the app window the pop-up goes away fine with the current date selected correctly, it just doesn't go away automatically like it would selecting a different date.

jay

[tbeernot]

That is a debatable feature to implement.

The CalendarPicker is of course unaware that it is being used in the popup of the CalendarTextField, so the CTF must use the information that the CP control makes available to decide if it should close the popup. The main trigger is the changing of the valueProperty (and that only in Date mode, in DateTime mode that won't close the popup). Now, if the value doesn't change, which is the case in your scenario, CTF can not know it should close the popup.

Controls in JavaFX have a clear separation between the control's API and how it is rendered (the skin). One should not expose skin details on the control's API. So if the skin does not change the value of the control, then there is no way I can tell who-ever-is-listening-to-the-control that something was clicked in the skin.

The only workable approach would be to set a new instance of the same date in the control's value, but I do not like that, because it makes thing look like something changed when in fact nothing did. So if you did not change anything in the popup, should should click outside the popup and it should close. Or press ESC.

Tom

You received this message because you are subscribed to the Google Groups "JFXtras Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jfxtras-user...@googlegroups.com.

[Jay Moss]

I understand your explanation from a technical standpoint, but from a user perspective it's kinda weird behavior:  if I click on any date except the currently selected one the popup disappears.  

As a user I expect my date selection (i.e. when I click on a day) to close the calendar - that's what I selected - even if I choose the same date.   

Comparing it with an old Swing calendar selector I used on a similar project the behavior there is consistent - selecting the current date closes the calendar and no change event is fired.  Clicking a day on the calendar is selection.

'Not a big deal, but I'm sure I'll get questions.

Thanks for all your help, I really appreciate it.

jay

[tbeernot]

I'll ponder on it some :-)

Tom

[tbeernot]

I have changed the behavior to match your suggestion, but one of the unit tests has a very strange error (it does not fail however), and this only happens in the unit test, I cannot reproduce it manually.

I need some staring down time.

Tom


On 2014-5-21 0:37, Jay Moss wrote:

[tbeernot]

The change should be available.

On 2014-5-21 0:37, Jay Moss wrote:

[Jay Moss]

thanks