Summary: | DateTime control: CALENDAR style returns zero hours, minutes, seconds | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Elias Volanakis <elias> | ||||||
Component: | SWT | Assignee: | Praveen <pinnamur> | ||||||
Status: | NEW --- | QA Contact: | Carolyn MacLeod <carolynmacleod4> | ||||||
Severity: | normal | ||||||||
Priority: | P3 | CC: | ekke, gheorghe, pinnamur | ||||||
Version: | 3.5.1 | ||||||||
Target Milestone: | --- | ||||||||
Hardware: | PC | ||||||||
OS: | Windows Vista | ||||||||
Whiteboard: | |||||||||
Attachments: |
|
Description
Elias Volanakis
2009-12-01 19:59:03 EST
Created attachment 153548 [details]
Snippet to reproduce bug
1. Open dialog
2. Hit OK
3. Look at console output
CALENDAR has zero hours, minutes, seconds. DATE and TIME have current h,m,s.
I believe this is caused by this code in getHours/Minutes/Seconds: int msg = (style & SWT.CALENDAR) != 0 ? OS.MCM_GETCURSEL : OS.DTM_GETSYSTEMTIME; OS.SendMessage(...) While this is valid for get Year, Day, Month, it seems unnecessary for H,M,S (since they are not choosable by the user). I would prefer to return the current H,M,S similar to the SWT.DATE and SWT.TIME styles. I'm not sure what the correct behaviour is here, but it is inconsistent between SWT.DATE and SWT.CALENDAR styles, which seems wrong. We just do what the platform control does (see the bottom of this page for Windows: http://msdn.microsoft.com/en-us/library/bb760913(VS.85).aspx) However, given that we called the control "DateTime", I suppose we probably should answer a valid time from a calendar. :) First, we should check what GTK and Cocoa Calendar do. If they answer a valid time, then we should do the same on Windows for cross-platform consistency. Windows and GTK does not return the current time for Calendar style, where as Cocoa returns the current time. I would prefer to make Window and GTK to return the current time as Cocoa, and also to eliminate the differences between Calendar and Date/Time styles. Car, any thoughts on proceeding further ? Should I make changes in Windows and GTK to have consistent behavior accross platforms ? Yes, go ahead and make Windows and GTK calendar return the current time. Try to do it using only the platform, so that we do not have to import the Java class java.util.Calendar, particularly on Windows, where both the "SWT.DATE/SWT.TIME" and the "SWT.CALENDAR" controls are native. DateTime on GTK already imports this class, but note that it is only used by the "SWT.DATE/SWT.TIME" emulated control. It would be best if you could avoid creating an instance of java.util.Calendar just to get the current time for the "SWT.CALENDAR" control. Maybe you can use time() and localtime_r() in time.h? Bog, do you know if those functions are available on all *nix systems that we support? Of course, note that by adding time support to native calendar controls that don't support time, we are actually "emulating" a small piece of these controls, so we need to be aware that these small pieces need extra testing across multiple locales and multiple (*nix and Windows) platforms. Created attachment 160072 [details]
Patch v01
Windows changes - The code is modified to query for the current time instead of selected time. So, Calendar control queries the same ways as Date/Time control now.
GTK changes - If the user didn't set time for Calendar control, then query the system for local time and then, return the current time.
Car, please review the patch and post your comments. If the code changes are fine, then I will release the code along with the natives. Thanks.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. |