Home › Forums › Konopka Signature VCL Controls (formerly Raize Components) › TRzDateTimeEdit Localization Issue
Tagged: TRzDateTimeEdit
- This topic has 7 replies, 2 voices, and was last updated 2019-03-03 at 12:21 pm by Olivier Beltrami.
-
AuthorPosts
-
-
February 20, 2019 at 2:44 am #1114
Hi,
I have a client in Quebec where the TRzDateTimeEdit control returns a date of 0 if he selects a date that displays in the control as “jeu. 01-août-2019” (using the format string “ddd dd-mmm-yyyy“).
Any idea what is causing this ? I’m not able to reproduce the issue here, with an English US locale, so I am guessing that the issue comes from the diacriticals. I’m willing to look at the code of the component, but any rough idea as to where I should look would be great.
Very best regards,
Olivier
-
February 20, 2019 at 9:49 am #1115
Just to clarify, what might not have been clear in my original post.
1) The user selects August 1, 2019, using the drop-down calendar and the mouse (no typing involved).
2) Once the calendar disappears, the control displays “jeu. 01-août-2019”.
3) after the control loses focus, it displays nothing (blank)
4) Calling the control’s Date method returns 0.Very best regards,
Olivier
-
February 20, 2019 at 11:11 am #1118
It’s me again.
I have been testing the component in the debugger with my problem string and see what the problem is:
1) A date is selected in the drop-down calendar.
2) That date is converted to a string using the Format property and displayed in the TEdit part of the component.
3) In the OnExit, the string is converted back from string to date using the function StrToDateEx() which tried to valiantly understand the format of my user, but fails. If I set UseFormatToParse to true the function fails by returning the date of today, if I set it to false (as was the case at my client site) the function fails by returning a date of 0.Is there a way to keep the date obtained in step 1, above, and avoid changing it to a string that then needs to be parsed back ?
Very best regards,
Olivier
-
February 21, 2019 at 12:16 am #1123
Hi Olivier,
I will need to do some research on this. What version of Delphi are you using?Ray
-
February 21, 2019 at 12:48 am #1124
I was able to reproduce the problem that you are experiencing. I changed the format settings for Windows to be French (Canada). I only changed the general Format setting. I did not change any of the actually date/time formats.
I then created a test project that has a TRzEdit and a TRzDateTimeEdit control on the main form. I put the TRzEdit so that I could tab into and out of the TRzDateTimeEdit. I also set the Format property of the TRzDateTimeEdit to ‘ddd dd-mmm-yyyy‘. I ran the app, click on the date-time edit and picked today’s date. I then clicked on the other edit control and that is when I got the exception.
After some investigation, I was able to see why the error was occurring. Let me try to explain. As you discovered, the TRzDateTimeEdit uses the StrToDateEx function to parse the information in the edit to determine the date. Because a user is able to enter a date in the control and not select one from the dropdown calendar, the data that gets parsed could be in a variety of formats. In order to interpret the data entered and match it to date elements, the system ShortDateFormat is used as a guide. Well, actually an abbreviated version of the ShortDateFormat is used. For example, the default ShortDateFormat for French(Canada) is yyyy-MM-dd. This gets condensed to YMD. For English(United States), the ShortDateFormat is M/d/yyyy, which gets condensed to MDY. And for English(United Kingdom) the format is dd/MM/yyyy, which gets condensed to DMY.
This approach is how the control is able to handle someone from the US entering 0405 into the control, tabbing away and the date is determined to be April 5. However, someone from the UK entering 0405 into the control will have the date determined to be May 4.
So, what does all of this have to do with what you are experiencing. Well, the condensed ShortDateFormat for French (Canada) as noted above is YMD. However, the Format property of the control is set to ‘ddd dd-mmm-yyyy‘, which gets condensed to DMY. And this is the problem. The parsing code is trying to match the values in the text area to YMD, but the year and day values are swapped. The parsing code ends up matching 2019 to the day value, which is clearly invalid.
The easiest solution is to change the Format property of the TRzDateTimeEdit control to ‘ddd yyyy-mmm-dd‘ so that it matches the YMD ShortDateFormat defined in the system.
Ray
-
February 21, 2019 at 1:24 am #1214
Hi Ray,
Thank you very much for looking into this, in depth, as usual.
Your solution would be a workaround for the French Canadian settings, but I have users in over 50 countries, with systems running in every European language as well as Chinese, Korean and Japanese. This issue is bound to come up again, somewhere, again.
I assume this was not the same in the TRzDateTimePicker, which I dutifully changed when moving to Delphi 10.3, as I was told it was deprecated (us Canadians are an obedient group).
Would it be possible to add an Allow Key Edit option to make this control avoid the back and forth of changing a perfectly valid date to string and then trying to parse it back to a date.
I have started to look at changing the source code to dis-allow key editing and just keep the date obtained from the drop-down calendar, but any hints as to where to plug myself in would be appreciated.
Very best regards,
Olivier
-
February 26, 2019 at 6:56 am #1223
Hi Olivier,
There are a few things that I would suggest. First, I would make a report to Embarcadero about this issue as they have been the owners of the components since 2015. Second, the simplest way to handle this for all your clients would be to blank out the Format property, which would use the System defined ShortDateFormat. As for modifying the source code yourself, the approach that I would take would be to do something similar to what is done in the StrToTimeEx function and that is to use the Format property to guide the property. The UseFormatToParse property was added to handle parsing Time values that include other elements not in a format. The same approach could be used to handle date parsing. The only challenge is that the condensing code would need to be tweaked a little to handle the leading ddd in your format string so that it does not get confused for the day elements.Ray
-
March 3, 2019 at 12:21 pm #1226
Hi Ray,
Thank you very much.
I’ll tweak the StrToTimeEx function to match my needs when the date format is “ddd dd-mmm-yyyy“ (this is hard coded so it’s not an issue).
Very best regards,
Olivier
-
-
AuthorPosts
- You must be logged in to reply to this topic.