|my issues with Dating Nebula's widgets [message #890164]
||Thu, 21 June 2012 10:47
| SlowStrider Mising name
Registered: July 2009
I (and probably many other people that create SWT/JFace/Eclipse applications) have a very simple goal: provide a user-friendly editor for dates in SWT/JFace. It should allow typing and selecting from a calendar and it should also be used for editing dates in table cells. I should be easy to bind to a Date property of my model objects.|
In my opinion the Nebula widgets are really cool and really easy to integrate in an application, until unfortunately in practice I encountered a few issues. In total it took me at least two work days to solve them and there is still one issue left which I didn't solve. Hopefully my post can contribute in making Nebula even better and save others some time when encountering these issues.
The most logical place to start for my requirement is the SWT DateTime widget. However we have the practical requirement that some date fields may be intentionally left blank (i.e. null). This is unsupported with this widget (https://bugs.eclipse.org/bugs/show_bug.cgi?id=178362).
I am using SWT Designer and it already supports the DateChooserCombo so logically I used this. I didn't find an IObservableValue for it, but using google I quickly found a short and simple implementation that extends WidgetValueProperty and reacts on the SWT.Modify event (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=246014).
For use in table cells I found the DateChooserComboCellEditor and it works nicely. Unfortunately it has a bug where a cell that has a null Date automatically gets the latest selected date when you start editing it even if you don't want to actually change anything. It is caused by doSetValue not allowing a null value to be set on the combo before editing starts. It can be solved by replacing "if (value instanceof Date)" by "if (value == null || value instanceof Date)". (I solved it without changing the source by extending DateChooserComboCellEditor).
DateChooserComboCellEditor also has a minor bug. When you get more experienced with editing dates, it is logical to "triple" click the right side of a cell. This is the location where the calendar button appears when the cell is being edited. When doing this quickly, the button cannot be clicked and instead cell editing stops. This problem is not present when waiting a small time after the double click. I accidentally stumbled upon the CellEditor method getDoubleClickTimeout() and overriding it to return 0 solves this issue.
Another small issue is that DateChooserComboCellEditor does not commit the cell value when pressing enter. This is easy to fix with a simple KeyListener.
Unfortunately the calendar in DateChooserCombo is absolutely not user friendly for entering years because it only has a month spinner. So when you want to use it for a birth date in the 1960's you will have to click at least 42 * 12 = 504 times. Workaround: don't use the calendar but edit the year field (possibly by using arrow up/down).
Therefore I evaluated using CDateTime instead. It looks very nice and doesn't have the problem with year selection (unless you wish to select years in other centuries) and works fine outside of table cells. The only thing I don't like about it is that it takes an unnecessary mouse movement and click to confirm the date. What I absolutely found fancy is that when setting a pattern that has no year field, the popup calendar automatically removes the possibility to select a year. (I use this for selecting a yearly period).
The first thing that struck me when using databinding is that CDateTimeObservableValue simply does not work. I solved this by making a WidgetValueProperty for it similar to that of DateChooserCombo. However it listens to SWT.Selection, I tried SWT.Modify first but this does not detect some manually typed date changes.
Unfortunately the CDateTimeCellEditor has two annoying bugs:
- It doesn't detect focus lost on the text field so that the edited value is not committed when navigating to another cell or worse: when pressing a save button. I tried fixing this by changing the source to add an extra focus listener on the actual text field, but the field also loses focus when the calendar is popped up. I tried to fix this by not stopping cell edit when isOpen() is true on the CDateTime. This seemed to work, but it does not work together with the Clear button, and in some other cases cell editing seems to stop prematurely. To avoid having to shave Yaks to fix this issue I decided to stop and use DateChooserCombo for cell editing until this issue is fixed. Perhaps it can be solved by using the same idea as the DateChooserCombo?
- When editing starts, the day part of the formatted date is selected. Expected behavior is: you can now type in another day. Actual behavior is: when you start to type, the key you pressed is entered twice when typing 1 or 2. When typing something else such as 3 nothing seems to happen. In this case, when you subsequently type a valid number (e.g. 3 again) it seems to be entered fine. Perhaps users could learn to deal with this, but it's certainly not nice. Moreover there is an extra bug: when you do it exactly like described and you commit the edited value (e.g. by editing another cell), the old date value is restored, not the value you just typed. The above problem also happens if you click to edit the month or year part before typing anything.
P.s. I used versions cdatetime 0.14.0, cwt 0.9.0, datechooser/formattedtext 1.0.0 snapshot (came with SWT designer).
Powered by FUDForum
. Page generated in 0.01721 seconds