Community
Participate
Working Groups
Build ID: I20080617-2000 Steps To Reproduce: 1. Set your system to a non-US locale (e.g. en_GB, en_NZ) that uses d/m/y date format. 2. Create an application using a DateTime in DATE mode 3. The date format is displayed as m/d/y More information: At the very least, DateTime needs to detect the default locale and respect the date formatting of the default locale. Better would be support for explicitly setting the locale and/or format.
Assuming Linux GTK. Carolyn, shouldn't the native widget just pick this up automatically?
It is not using the native widget in DATE mode, it is setting the text of the Text field directly using the getFormattedString() method, which as you can see is hardcoding m/d/y format: String getFormattedString(int style) { ... /* SWT.DATE */ int y = calendar.get(Calendar.YEAR); int m = calendar.get(Calendar.MONTH) + 1; int d = calendar.get(Calendar.DAY_OF_MONTH); if ((style & SWT.SHORT) != 0) return "" + (m < 10 ? " " : "") + m + "/" + y; return "" + (m < 10 ? " " : "") + m + "/" + (d < 10 ? " " : "") + d + "/" + y; } This comment in setFormat() is fairly telling also: /*public*/ void setFormat(String string) { checkWidget(); // TODO: this needs to be locale sensitive In other words, this is an incomplete implementation. IWBNI this class could be marked as being a work in progress...
working with enterprise applications you should be able to display and enter date and time in different locales. so I would like to be able to setLocale() at DateTime - if nothing is set, the current Locale is choosen. ekke
I can confirm this is also an issue with Windows XP Pro. There is nothing in the Preferences (logically under General: Appearance) to set the desired behaviour. This problem is more complex than it may appear at first glance. Looking just at the displayed date-time strings in the Error Log, we could set Eclipse to either use the date-time parameters of: * its current nl setting * the underlying operating system's (for that language) * the underlying operating system's for the language that it runs that Eclipse instance under * the underlying operating system's for its native language This is because one could be running French Canadian Windows XP with an English Canadian Eclipse instance that has been launched in English US mode (-nl en_US).
Any news about this bug? Over 3 years passed and it still looks wrong under linux.
In addition to using the system locale for date/time display, it should also be possible to specify a 24 hour time (see bug 337468)
I have the same issue. This is the only workaround I have come up to: public class DateTimeWithFormat extends DateTime { public DateTimeWithFormat(Composite parent, int style, String format) { super(parent, style); TCHAR lpszFormat = new TCHAR (0, format, true); OS.SendMessage (handle, OS.DTM_SETFORMAT, 0, lpszFormat); } /** * Do not throw an error upon subclassing detected */ protected void checkSubclass () { } } i.e. subclassing DateTime (even if not allowed) and using DTM_SETFORMAT OS message.
oops sorry, did not see DateTime.handle was public... it makes things a lot easier: The following code is valid for a Windows platform. Don't know what if it is legal/it works on Linux. // create the control DateTime dateControl = new DateTime(...); // then change its date format to the pattern you like TCHAR lpszFormat = new TCHAR (0, pattern, true); OS.SendMessage (dateControl.handle, OS.DTM_SETFORMAT, 0, lpszFormat);
Is there any chance of resolving this? It is really annoying that you can't really control the display format. The best would be if a Dateformat could be set on the control so you can format it how ever you like it (and not depend on only locale settings)
New Gerrit change created: https://git.eclipse.org/r/116904
New Gerrit change created: https://git.eclipse.org/r/116927
okay I provided a gerrit patch that adds localization support to date/time controls in the text-box. You can even control the used locale for the textbox / input format but the drow down is always the current system locale.
(In reply to Eclipse Genie from comment #11) > New Gerrit change created: https://git.eclipse.org/r/116927 Gerrit down atm. But tennativley I tested on gtk2/gtk3, looks pretty good. I'll try to take another look next week or when gerrit is up again.
Gerrit change https://git.eclipse.org/r/116927 was merged to [master]. Commit: http://git.eclipse.org/c/pla.git/commit/?id=da784537d1cd1e9a3d177d19e9dc4273f84814eb
New Gerrit change created: https://git.eclipse.org/r/117213
Gerrit change https://git.eclipse.org/r/117213 was merged to [m]. Commit: http://git.eclipse.org/c/www.git/commit/?id=8a11b268e0ddab691a2fabfde66394a32e8c0cac
(In reply to Christoph Läubrich from comment #12) > okay I provided a gerrit patch that adds localization support to date/time > controls in the text-box. > You can even control the used locale for the textbox / input format but the > drow down is always the current system locale. Thank you very much for your patch submission! This fixes the highest voted Gtk bug. Patch is much appreciated!. I updated the snippet website to link to snippet370 and added a N & N entry, (feel free to improve on the N & N entry thou). Thanks!
With this patch running Snippet 250 in the dropdown case (middle widget) if I edit the text field from 'Feb 16, 2018' to 'Feb 17, 2018' and click the drop down button to see the calendar it still points to Feb 16. Reverting the patch fixes the behavior. Please either fix or revert ASAP.
I'll take a look I'm just not sure if this should be tracked by a new bug? Can you test that changing to another field (e.g. pressing tab button) yields correct date in the dropdown?
(In reply to Christoph Läubrich from comment #19) > I'll take a look I'm just not sure if this should be tracked by a new bug? > Can you test that changing to another field (e.g. pressing tab button) > yields correct date in the dropdown? It is a regression from the patch in this bug so should be tracked here. Navigating with tab and arrows updates the calendar just fine. So the issue is only when editing manually and not navigating to another field in the calendar (if you navigate it's updated proper).
Can you try if adding commitData(); as the first line to private void setCurrentDate () fixes the problem for you? The problem is to decide what should happen when in "edit" mode and the user press the drop down button? Should we try to commit the current edit? That might revert the user changes if incomplete/invalid data is added. Or should we display the last commited data (as it is right now), or try to parse the current input and only update the poup if it is valid...? Beside this how to provide a patch or this? Greate a new gerrit review (from current master) or modify the existing review by adding a new patch set?
Two other things I noticed regarding this: - if the window with the datecontrol goes to background, the popup window stays foreground (even if other windows get focus) has anyone an idea how to fix this? - if the poup is open the and you type what should happen: a) the popup closes b) the popup stays open but updates if the data changes any thoughts?
Okay I think that changing /** * Calculates appropriate width of GtkEntry and * adds Date/Time string to the Date/Time Spinner */ @SuppressWarnings("deprecation") void setText (String dateTimeText) { if (dateTimeText != null){ byte [] dateTimeConverted = Converter.wcsToMbcs (dateTimeText, true); //note, this is ignored if the control is in a fill-layout. GTK.gtk_entry_set_width_chars (textEntryHandle, dateTimeText.length ()); GTK.gtk_entry_set_text (textEntryHandle, dateTimeConverted); if (popupCalendar != null) { try { Date parse = dateFormat.parse(dateTimeText); popupCalendar.setDate (parse.getYear()+1900, parse.getMonth(), parse.getDate()); } catch(Exception e) { //ignore then } } } } has the best result, since this updates the calendar (even while typing if popup is open) as soon as there is a valid date in the text field. You can then navigate by text or by calendar through the dates.
(In reply to Christoph Läubrich from comment #23) > Okay I think that changing > > /** > * Calculates appropriate width of GtkEntry and > * adds Date/Time string to the Date/Time Spinner > */ > @SuppressWarnings("deprecation") > void setText (String dateTimeText) { > if (dateTimeText != null){ > byte [] dateTimeConverted = Converter.wcsToMbcs (dateTimeText, true); > //note, this is ignored if the control is in a fill-layout. > GTK.gtk_entry_set_width_chars (textEntryHandle, dateTimeText.length ()); > GTK.gtk_entry_set_text (textEntryHandle, dateTimeConverted); > if (popupCalendar != null) { > try { > Date parse = dateFormat.parse(dateTimeText); > popupCalendar.setDate (parse.getYear()+1900, parse.getMonth(), > parse.getDate()); > } catch(Exception e) { > //ignore then > } > } > } > } > > has the best result, since this updates the calendar (even while typing if > popup is open) as soon as there is a valid date in the text field. You can > then navigate by text or by calendar through the dates. Tested and it seems to fix the issue. Would you please submit gerrit review that doesn't use deprecated methods?
(In reply to Christoph Läubrich from comment #22) > Two other things I noticed regarding this: > - if the window with the datecontrol goes to background, the popup window > stays foreground (even if other windows get focus) has anyone an idea how to > fix this? > - if the poup is open the and you type what should happen: > a) the popup closes > b) the popup stays open but updates if the data changes > > any thoughts? IMHO b)
New Gerrit change created: https://git.eclipse.org/r/117582
(In reply to Alexander Kurtakov from comment #24) > Tested and it seems to fix the issue. Would you please submit gerrit review > that doesn't use deprecated methods? I have submitted a review. Can you test/review it?
The New and Noteworthy entry is not good. The entry is listed under PDE instead of Platform. Also, we usually do not link to bug reports in the N&N.
(In reply to Dani Megert from comment #28) > The New and Noteworthy entry is not good. The entry is listed under PDE > instead of Platform. Also, we usually do not link to bug reports in the N&N. > instead of Platform. Actually, it should be moved to the 'Platform Developers' section. The title and text are not horizontally aligned. See other items how it should look like.
New Gerrit change created: https://git.eclipse.org/r/118071
Gerrit change https://git.eclipse.org/r/118071 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=8429c9cde25e0ecb796f27e9260bb010ce6010c2
(In reply to Dani Megert from comment #28) > The New and Noteworthy entry is not good. The entry is listed under PDE > instead of Platform. Also, we usually do not link to bug reports in the N&N. Thanks. Fixed via: https://git.eclipse.org/r/#/c/118071/
Gerrit change https://git.eclipse.org/r/117582 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=113e773e53e827e2495b0710e781964bc40d9674
This seems fixed now. Thanks Christoph
(In reply to Leo Ufimtsev from comment #32) > (In reply to Dani Megert from comment #28) > > The New and Noteworthy entry is not good. The entry is listed under PDE > > instead of Platform. Also, we usually do not link to bug reports in the N&N. > > Thanks. Fixed via: > https://git.eclipse.org/r/#/c/118071/ Not really. See https://www.eclipse.org/eclipse/news/4.8/M6/ Comment 29 is still an issue. Please fix. Thanks.
New Gerrit change created: https://git.eclipse.org/r/118182
Gerrit change https://git.eclipse.org/r/118182 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=861241c27770351a362622c2040ef8a4a1e77145
(In reply to Dani Megert from comment #35) > Comment 29 is still an issue. Please fix. Thanks. I moved to "Platform developers" section and changed alignment to be like other items.
(In reply to Leo Ufimtsev from comment #38) > (In reply to Dani Megert from comment #35) > > Comment 29 is still an issue. Please fix. Thanks. > > I moved to "Platform developers" section and changed alignment to be like > other items. Thanks!
Added picture to N&N: https://git.eclipse.org/r/#/c/118202/
New Gerrit change created: https://git.eclipse.org/r/118202
Gerrit change https://git.eclipse.org/r/118202 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=b2fc4871eec603f99accda50d3e5ab165fb3fc50
Alex/Leo, can you please verify this one?
I found 2 regressions with this patch: Snippet251. - Middle widget, clicking (*with mouse*) on "+ or -" changes date by '2' units at a time. e>g 10 -> 12 -> 14. - Days aren't incremented as expected, once you go beyond 30, it jumps back and fourth between 31 and 01. - In general, clicking for this widget doesn't seem functional. But using up/down seems to work as expected. Snippet 250. - Middle widget, click on drop down button to get calendar. - Clicking on a date once doesn't make it calendar box dissapear, only clicking twice. Previourly clicking on the calendar once was enough. -> suggestion to investigate selection/default selection. If you're using default selection, use selection or single mouse-down. @Christoph Läubrich, is it possible for you to investigate what went wrong? Snippet250 is not deal breaker, can be fixed later. But the Snippet251 is somewhat buggy.
I'll take a look. I agree that the selection/clicking is confusing in this widget but I haven't found a reliable way to handle it better because for me GTK behaves fuzzy sometimes, or I just don't know enough about GTK to understand why it works that way. For example if you click inside a field it gets selected and is visually highlighted, if you click again (e.g. between two numbers) the blue selection disappears, but the widget still reports the selection is present (and even forcefully setting it again does not bring back the old blue selection). I also tired to use the carret position to determine where the user clicked, but this also yields strange behavior because it sometimes reports the carret is at 0,0 and this messed up the whole handling. As mentioned before I also noticed that the popup stay on top if the main window goes to background or is minimized, and the widget seems to behave different if it is the only one (all text is selected on start) or if more than one are active. From the first focus on the selection behaves as expected. So if there is an GTK expert out there to help out or anyone has an hint it would be appreciated.
New Gerrit change created: https://git.eclipse.org/r/118965
(In reply to Leo Ufimtsev from comment #44) > I found 2 regressions with this patch: > > Snippet251. I fixed this now and provided a new patch > Snippet 250. > - Middle widget, click on drop down button to get calendar. > - Clicking on a date once doesn't make it calendar box dissapear I have checked the code but it seems to use some special handling: - if a user changes the year/month keep the popup open - if user changes the day close the popup this is done by some status variables and even though I have not changed in this area it now seems to need two "date-changes", anyone has an idea what might leads to this?
(In reply to Christoph Läubrich from comment #47) > (In reply to Leo Ufimtsev from comment #44) > > I found 2 regressions with this patch: > > > > Snippet251. > I fixed this now and provided a new patch > > > Snippet 250. > > - Middle widget, click on drop down button to get calendar. > > - Clicking on a date once doesn't make it calendar box dissapear > I have checked the code but it seems to use some special handling: > > - if a user changes the year/month keep the popup open > - if user changes the day close the popup > > this is done by some status variables and even though I have not changed in > this area it now seems to need two "date-changes", anyone has an idea what > might leads to this? Hello Christopher, Snippet251 works well, nice. For snippet250: I've very briefly fiddled around with day-selected & day-selected-double-click (see how they connect, search DAY_SELECTED, DAY_SELECTED_DOUBLE_CLICK gtk_day_selected_double_click, gtk_day_selected_double_click) But haven't got it to work stable. Sometimes the calendar would work on single click, sometimes two clicks are needed. Have you already investigated these two signals? If you could spent a few hours researching this and see if there is a way to fix these signals, it would be great. But if you spent a lot of and find that it's still more stable with double-click, then we could keep the double-click behavior. Let me know. https://developer.gnome.org/gtk3/stable/GtkCalendar.html
New Gerrit change created: https://git.eclipse.org/r/119030
(In reply to Leo Ufimtsev from comment #48) > If you could spent a few hours researching this and see if there is a way to > fix these signals, it would be great. I think I fixed this now (see new gerrit change) by throwing away the gtk signals and capture state at mousedown and check for change on mouseup that seems to work reliable.
Gerrit change https://git.eclipse.org/r/118965 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=b90e2d129c2f64b69badd63d13d19a87190a6179
http://download.eclipse.org/eclipse/downloads/drops4/I20180311-2000/testresults/html/org.eclipse.swt.tests_ep48I-unit-cen64-gtk3_linux.gtk.x86_64_8.0.html This caused errors in the JUnit tests.
Too bad that SWT tests are only using the previous built version so that the build in the Gerrit change did not detect this. @Christoph: Could you have a look at those tests? Otherwise we would have to revert the change soon.
If I run the test on my local computer everything is fine, so I suspect I have to setup something first?
That will be hard, since you don't have that environment. I guess it is hard to set up. But when you provide a Gerrit it will pick up your change and run a build on Jenkins, and you might be able to fix it that way. The build for the change will fail first, and then try to find a change that fixes it.
New Gerrit change created: https://git.eclipse.org/r/119210
I created a new gerrit and added some system-out to see whats going on, but the build passes without a problem: https://ci.eclipse.org/platform/job/eclipse.platform.swt-Gerrit/6339/ any ideas?
Not yet. And I also do not see how your change and the test failure could be related. The last 3 builds were all OK, so there might be no issue. @Alex: How do we proceed? I think the dummy change can be abandoned and this ticket be closed again. WDYT?
(In reply to Karsten Thoms from comment #58) > Not yet. And I also do not see how your change and the test failure could be > related. > The last 3 builds were all OK, so there might be no issue. > > @Alex: How do we proceed? I think the dummy change can be abandoned and this > ticket be closed again. WDYT? Hello Karsten, I've ran jUnits locally. (Fedora 27, Gtk3.22, x11). They all pass. And the recent builds also all pass. I'm not exactly sure why the inconsistency occurred, I guess there was a delay in rebuilding the jUnits. But if there's no problem, then all is well :-). With that said, @Christoph, about the double-click business in snippet250. Do you think it's possible to play around with the select-day signals and get it to work via single click, or is it too unstable with single click and keep it at double click? Do you know why the behavior changed after patch? wdyt?
(In reply to Leo Ufimtsev from comment #59) > With that said, @Christoph, about the double-click business in snippet250. You reported here https://git.eclipse.org/r/#/c/119030/ that my first approach seems to not work for you, I think we can try to evaluate there a little bit more I just wonder if I should create a new patch based on current master (since current patch conflicts)? Can you also describe the environment where it does not worked? I'll then try to find a fix for this.
(In reply to Christoph Läubrich from comment #60) > (In reply to Leo Ufimtsev from comment #59) > > With that said, @Christoph, about the double-click business in snippet250. > > You reported here https://git.eclipse.org/r/#/c/119030/ that my first > approach seems to not work for you, I think we can try to evaluate there a > little bit more I just wonder if I should create a new patch based on > current master (since current patch conflicts)? Can you also describe the > environment where it does not worked? I'll then try to find a fix for this. You could either rebase the patch on current master or start a new one. (Usually if you start a new one, you can copy the change-id and it will add a patch-set instead of new patch). My env is: Fedora 27, Gtk3.22, x11. But any Gtk3.22 env should be fine
New Gerrit change created: https://git.eclipse.org/r/119245
It seems gerrit only accept the same Id if I ammend the commit, since there are commits in between this does not seem to work, so I have created a new change and testes the following on my local maschine run Snippet250 with SWT_GTK3=1, - if I click on the Mont/year "arrows" -> year/month changes in the textfield and the calendar - if you click on a day -> the calendar closes and the textfield shows the selected day Debian 4.9.82-1+deb9u3 (2018-03-02) x86_64 GNU/Linux, if I understand right 3.22.11-1 and 2.24.31-2 are installed on my system.
Gerrit change https://git.eclipse.org/r/119245 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=0d2cdd87c97d635b14e4e98e679e77c2a4d01dbe
(In reply to Christoph Läubrich from comment #63) > It seems gerrit only accept the same Id if I ammend the commit, since there > are commits in between this does not seem to work, so I have created a new > change and testes the following on my local maschine > > run Snippet250 with SWT_GTK3=1, > > - if I click on the Mont/year "arrows" -> year/month changes in the > textfield and the calendar > - if you click on a day -> the calendar closes and the textfield shows the > selected day > > Debian 4.9.82-1+deb9u3 (2018-03-02) x86_64 GNU/Linux, if I understand right > 3.22.11-1 and 2.24.31-2 are installed on my system. Thank you for patch. Now everything works well :-). Verified on Snippet250,Snippet251,Snippet370,ALLTests. Gtk3.22. X11. Thank you so much for all your work!
Many thanks for the efforts of all, most especially Christoph. Can't wait to use it!
*** Bug 339725 has been marked as a duplicate of this bug. ***
*** Bug 177981 has been marked as a duplicate of this bug. ***
