This is my first approach for a ControlsFX TimePicker control. It has a look and feel like the JavaFX DatePicker.
The value is a LocalTime which might be post-processed with any Zone.
A precision can be selected which changes the shown segments in the TimePicker popup. Currently it has support for hour/minute/second precision, but can be extended with eg millis or even nanos in the future.
A converter can be set which converts the string to a value and vice versa.
A specified locale can be set to force a AM/PM or 24h hour selection.
This pull request is a result of issue #463, but is not a full implementation of that proposal.
This is not a very critical bug, but something I observed when having a TimePicker immediately along side a DatePicker... When you click on the button on the DatePicker while the combobox is open, it closes the dropdown. With the TimePicker, however, it closes and immediately re-opens again. In order to close the TimePicker dropdown, I have to focus away from the control.
I set a TimePicker via the API to be at a certain time (in this case, 8:40am). When I open the application and click the button on the control, the 8 and 40 cells are selected. However, when I select a different cell (for example, 41), the time jumps from 8:40 to 12:41. So it would seem that some part of the internal state thinks it is 12 am, not 8 am.
I think this needs to be fixed for Jdk8u60. I don't have that installed on this system, but I saw another developer with that version installed, and there was a complaint in the IDE about unimplemented abstract methods.
One question: Will the next ControlsFX release be based on 8u60? I found out that there has to be done some work in TimePickerSkin because there are major changes introduced in 8u60 in ComboBoxPopupControl...
Hi @Jonathan Giles, the TimePicker component doesn't work with 8u60+ because of API changes in at least ComboBoxPopupControl. I don't know how to proceed, because custom controls like my TimePicker are often based on original JavaFX skins. They are internal API of JavaFX and theirfor are allowed to change. I often read here that ControlsFX will not use any internal API anymore. But how should we implement custom controls without using base JavaFX skins and so on? What is the strategy of ControlsFX for this point?
Now that Java 9 has been released and we have a 9.0.0 branch in ControlsFX, would you like to check if the issue is resolve in Java 9? If yes, would you like to work on the PR to target the same to 9.0.0?