Community
Participate
Working Groups
I'm using a DateTime(SWT.CALENDAR) control in a date picker dialog. When clicking on a 'day' the dialog should be dismissed, clicking on the next/previous month/year arrows, the dialog should stay open. Problem: the selection event does not provide any information about what part of the dialog was clicked. In addition, the SelectionListener's widgetDefaultSelected method is never called. This is on MacOS X.
Can you add an OK button for now? Historically, the SWT selection event does not provide additional information. It is typically up to you to look at the control and see what changed. I can see that that won't work for calendars because the day can change when the user changes the month, etc. But, you're right, DefaultSelection is currently spec'ed to do nothing for DateTime on all platforms. So it could concievably be used to say "the user actually selected a day, they are not just navigating". I see that the Windows calendar has an MCN_SELECT event that is sent "when the user makes an explicit date selection within a month calendar control". The GTK calendar has a signal that is "Emitted when the user selects a day". Mac Carbon doesn't have a calendar, so what you are seeing is emulated (so we can make it do anything as long as it's consistent with the other platforms). I will run this by Steve when he gets back next week.
FYI, I put up a new snippet: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet251.java
Normally, widgetDefaultSelected() is for "double clicking" or default action, not "single clicking".
See also bug 177764.
*** Bug 177776 has been marked as a duplicate of this bug. ***
*** Bug 178625 has been marked as a duplicate of this bug. ***
So, are there any plans to introduce the DefaultSelection (widgetDefaultSelected()) event? Technically, it is acknowledged as possible and it's especially useful when the DateTime control is shown in a popup window that must go away...
CAR, just fix this?
We need to decide whether default selection will be send for single clicking. Note that this is unexpected. Normally, default selection is sent when the user double clicks or hits return. If we decide against "default selection on single click", we use the detail field in the selection event. This seems like the right thing to do to me. If we decide to do this (the detail), we might also implement the "double clicking and return behavior" for default selection in addition to the detail field.
I second this request. Being able to distinguish between day-selections and navigation-selections would allow one to dismiss the dialog as soon as the date was explicitly changed without navigating. Using the detail field on the selection event seems like a good strategy. I am not sure if the default selection event is necessary at all then.
Well, the DefaultSelection event IS necessary. Navigation and single-clicking on a calendar day should result in a Selection event being fired. On the contrary, double-clicking and <Enter> on a calendar day should produce a DefaultSelection event. These are the natural expectations. The Event's detail field seems unnecessary, then.
Right. One might want to be able to close the calendar once a day was selected. You need the selected date as part of the selection event in this case to distinguish from a navigation event.
The DateTime class is endowed with some getXyz() methods that supply the currently chosen date and time at any point in code. If navigation events and selection events (single-click only) can be told apart, then I suggest the detail field (which is of type "int", by the way) contained a constant from org.eclipse.swt.SWT indicating that it's about navigation action (maybe the TRAVERSE_* constants?).
Yes, I was thinking into the same direction.
Released SWT.DefaultSelection code for Windows.
Just checking, is the default selection event now available?
Steve, You said that the the SWT.DefaultSelection code is available for Windows. Is the patch available for general use, and for the other platforms? Regards, Karthick
I have the same problem on windows and presumably on debian latter. I want to show a DateTime calendar without the ok button. When the user really chooses a day, I will get the day and close the dialog. When the user just changes the month, i will not close the dialog. I tried to test if the month had changed, but this is defeated in case the user chooses a day (pale grey color) outside the current month. People here have suggested to detail the event so that we know if the user is navigating or making a decision. This would be very fine. I read also about default selection, which is not quite clear for me, because I dont imagine the user double cliking or hitting enter on a calendar - but if it achieves the same result, why not ? As the last message here is dated september, may I ask if any correction is available ?
Fixed > 20090429. DefaultSelection is now implemented for calendar (double-click on date). If you are using the DATE or TIME component of a DateTime, then DefaultSelection is sent when the user types CR. Dialogs containing DateTime controls can now be closed on DefaultSelection.
