Community
Participate
Working Groups
When using a CDateTime widget with CDT.DROP_DOWN in a JFace dialog, the drop down cannot be closed by clicking outside of the calendar/clock. The calendar can be closed by choosing a date or pressing "ESC", but the analog clock can only be closed by pressing "ESC", which cancels the selection (it is impossible to change the time using the dropdown) This problem occurs at least on win32 and OS X When using the widget in a RCP view, it behaves as expected. If the standard behavior is not possible to implement in a dialog, there should be at least "close" and "ok" buttons to help the user.
There is no way to get out of the CDateTime editor, except by pressing Cancel or by clciking on "Today is ..." button or by clicking on a date on the calendar. Is there anyway to close the CDateTime editor if the user click anywhere outside the window that CDateTime is displayed in. This would be the behavior analogous to a combobox.
The culprit appears to be AbstractCombo.createContentShell(). If the shell that contains the CDateTime is modal, this method creates a modal popup for the pickers. Since the pickers are in a modal Shell, events on the background Shell (including events on the CDateTime) are ignored.
Jeremy, I just commented out the whole case check on the parent shell's style, and everything seems to work fine. There doesn't appear to be a need for the popup to be modal. Do you remember why you did this originally?
There was a bug in SWT where controls on a dialog would not generate any events when the dialog's parent was a modal dialog, unless it too was modal. This meant that, while you could open and close the popup correctly, you could not interact with it at all. So, I put in this hack to at least make the widget usable. There's more history somewhere in bugzilla and on the SWT newsgroup, but that's the gist of it.
I checked Peter's fix on OSX, it works fine and pickers are usable. It seems that the workaround is no longer necessary. Can it be removed ?
Jeremy, I've been unable to find the SWT bugzilla report for the modal dialog issue. If you could point me to the right bug, I'll put in a conditional check for SWT.getVersion() < fix, so that it will continue to function (this bug notwithstanding) on older releases of SWT. I think a reasonable, non-intrusive workaround for older SWT versions would be to commit changes from the popup when the Enter/Return keys are pressed. CCombo has a similar behavior, as do standard Combos on Win32. Personally, I'd like to have commit-on-enter anyway.
HEAD now includes an SWT.getVersion() check. Since I don't know exactly what SWT revision fixed the bug Jeremy mentioned, I'm using 3346, which is the current 3.3 final release. This value is stored in a non-final protected static field, so that it is easier to test previous versions. You can do so by creating a new subclass of CDateTime and simply assign this field the value of SWT.getVersion() in the constructor. If events are delivered to the popup as expected, please let me know the value, and I will update it. It would be particularly useful to know if this bug is still present in the 3.2 or 3.2.1 official releases.
I've recently hit this bug, I don't know if it is a regression or what, my SWT version is 3349 and it doesn't work. If I set SWT_MODAL_FIX_VERSION to 3400 the calendar works. The widgets is placed on a page of an import wizard, if that matters.
Tried on latest SWT version, the bug seems to be fixed
