Localize date picker tooltips inside Header Context Menu + date format bug

[Massimiliano]

I've been trying to access and localize the pickers but with no success... Here are my test so far (it doesn't work of course).

Protected Sub Page_Load(sender As Object, e As EventArgs) Handles Me.Load
     AddHandler RadGrid1.HeaderContextMenu.ItemCreated, New Telerik.Web.UI.RadMenuEventHandler(AddressOf HeaderContextMenu_ItemCreated)
 End Sub

 Protected Sub HeaderContextMenu_ItemCreated(sender As Object, e As Telerik.Web.UI.RadMenuEventArgs)
     If TypeOf e.Item Is RadDatePicker Then
         Dim picker As RadDatePicker = DirectCast(e.Item, RadDatePicker)
         picker.DatePopupButton.ToolTip = "Apri il calendario"
     End If
 End Sub

Also I discovered a very odd issue with the context menu while filtering datetime columns. If you set a culture with dd/MM/yyyy (italian for example) with 

       Protected Sub Page_Load(sender As Object, e As EventArgs) Handles Me.Load
            If Not Me.IsPostBack Then
                RadGrid1.Culture = New CultureInfo("it-IT")
            End If
end sub

If I select 6/7/2013 (wich stands for July, 6 2013) in the first (or second) filter of HeaderContextMenu, this is correctly reported as 06/07/2013 in the GridDateTimeColumn where FilterDateFormat="dd/MM/yyyy" and DataFormatString="{0:dd/MM/yyyy HH:mm}" BUT is incorrectly reported (after filtering) as 07/06/2013 AFTER filtering happened.
I mean... in the context menu, I see italian calendar, I select the correct dd/MM/yyyy date and this appears correct in the textbox when I click on the date BUT after the filtering happens (postback) if I go back to the header context menu I see month and day inverted in the textbox like MM/dd/yyyy. Guess this is a bug of sort. Any suggestion to solve while waiting for bugfix?

Thanks in advance 

[Massimiliano]

Wandering through undocumented stuff it's not funny but sometimes you are able to achieve the expected results.
This is how I solved localization for datepicker tooltips inside HeaderContextMenu (also I remove from the show/hide section some columns)

Protected Sub HeaderContextMenu_ItemCreated(sender As Object, e As Telerik.Web.UI.RadMenuEventArgs)
    ' Remove command columns from show/hide context menu
    If e.Item.Value.Contains("CommandSelect") Or e.Item.Value.Contains("CommandEdit") Or e.Item.Value.Contains("CommandDelete") Then
        e.Item.Visible = False
    End If

    ' Localize datepicker inside context menu
    If e.Item.Value = "FilterMenuContainer" Then
        DirectCast(e.Item.FindControl("HCFMRDPFirstCond"), RadDatePicker).DatePopupButton.ToolTip = "Apri il calendario"
        DirectCast(e.Item.FindControl("HCFMRDPSecondCond"), RadDatePicker).DatePopupButton.ToolTip = "Apri il calendario"
    End If
End Sub

About the other issue I still think it is a locale display bug and still have to find a workaround for it. Waiting for someone from telerik to confirm it. Here is a screenshot to better explain what happens. The search is correctly filtered. In the Grid the picker and filter textbox are displayed correctly but in the HeaderContextMenu filter, the picker shows another locale (MM/dd/yyyy instead of dd/MM/yyyy).
Screenshot: HeaderContextMenu filter date bug

[Vasil]

Hi Massimiliano,

Currently what happens is that your picker has one culture and the grid another. The picker populates the values in the filter menu, but the grid read them when creating the filter expression.

Set Culture to the whole Page to avoid this problem. If you want to do it dynamically then use the InitializeCulture as shown here:
http://msdn.microsoft.com/en-us/library/bz9tc508%28v=vs.100%29.aspx

Regards,
Vasil
Telerik

[Massimiliano]

Hallo Vasil,
thank you again for your support.
Tried your solution but with no success... here is the implementation (very easy) in a base page 

' Overrides culture info for the page
Protected Overrides Sub InitializeCulture()
    Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture("it-IT")
    Thread.CurrentThread.CurrentUICulture = New CultureInfo("it")

    MyBase.InitializeCulture()
End Sub

Not only the issue remains but if I remove the RadGrid1.Culture = New CultureInfo("it-IT") property in the actual page the grid won't even be translated anymore just like that this override for the whole page, doesn't have any effect on the Grid unless you set its culture explictly.

I still think it's a RadGrid bug on how Grid culture is propagated to the header context menu datepickers (filter text inside the context  menu is correctly translated, only the dateformat is wrong)

[Vasil]

Hello Massimiliano,

The grid use the culture of the Page, as well as all other RadControls including the DatePicker and DateInputs.
When setting the culture globally for the page, you should not set it per control and it still will be applied. If it is not applied, then the global set is not working for some reason. Could you confirm that the code executes? And during the Page_Load the controls in the page have 'it-IT" culture set when you debug.

Regards,
Vasil
Telerik

[Massimiliano]

Hallo Vasil, I suspected what you are saying but since the implementation was straightforward, I admit I didn't care to debug for this.
I will check and report back. Anyway in the worst scenario I guess there should be a way to set datepickers culture inside Header Context Menu? The odd thing is that BEFORE postback they behave like they should and show the correct format after selecting the date in the calendar, AFTER the postback this doesn't happen and this seems quite odd to me. It's like that BEFORE postback they inherit culture from the Grid but AFTER postback this doesn't happen.

Going to investigate more on both things discussed here and report back

[Massimiliano]

Ok Vasil, the ovveride wasn't working as expected because I just specified "it" in the CurrentUICulture (following blindly MS example) instead of repeating "it-IT".
I corrected, I can confirm (debugged) that the culture is applied to the whole page and to the grid as well (debugged checking for RadGrid.Culture) BUT the date inside the Header Context Menu is still inverted MM/dd/yyyy instead of the "it-IT" version wich is dd/MM/yyyy.
Also again I confirm this happens only after postback. Before postback the date is selected and reported correctly in the textbox, after postback it's inverted to MM/dd. ALSO I confirm again that both before and after postback, all the localized filtering texts AND the datepicker show correctly in the italian format BUT after postback just the date in the picker textbox loose the dateformat and go back to default MM/dd.

I really think is a bug :D Otherwise, if localization wasn't applied at all, both the whole grid and the header context menu (and the calendar of the picker) should have lost it after postback but that's not the case. Just the dateformat inside header context menu, after filtering happens, seems to ignore the locale.

If this wasn't an implementation bug I think It should have worked from the start with just RadGrid1.Culture = New CultureInfo("it-IT") because all the texts, the calendars (both in the grid and context menu) are always correctly localized both before and after filtering.

[Vasil]

Hi Massimiliano,

First I should note that the Grid creates only one menu, and when you open it for different columns, the data for each column is populated into the inputs in the filter menu.

The grid keeps the filter values as strings, and pass them to the control in the filter menu. In case the filter value is date or time, the RadGrid use Date.parseLocale to evaluate it.

So when filter using 6/7/2013 (July, 6 2013). This string will be applied to the filter, and stored in the grid. When you open the filter menu after post back, Date.parseLocale("6/7/2013") will be used to parse the value, and pass it to the DateInput. And here is the problem, by default this will return "7 June 2013", because, unless the asp ScriptGlobalization is turned on.

I would suggest you to set EnableScriptGlobalization=true, for your ScriptManager to resolve the problem. See this for more information:
http://msdn.microsoft.com/en-us/library/system.web.ui.scriptmanager.enablescriptglobalization.aspx

Regards,
Vasil
Telerik

[Massimiliano]

Thank you vasil for the tip I will try and report back.

[Massimiliano]

Sorry for late reporting, I've been on holydays :)
I tryed to set  EnableScriptGlobalization="true" on RadScriptManager. What happens now is this: 
- If I choose the date in the column filter box with the datepicker (or by hand), in the context menu filter box (and date picker) the month and days are always inverted (nothing changed)
- If I choose the date in the context menu and apply the filter from there, the value remains correct with the day and month in the right place, both in the column box and in the context menu box.

So it seems the setting did a little improvement in that inside the context menu, if you apply filtering from the context menu, values are correct in every place. The issue still persist if you apply the filtering from the "regular" column datepicker, since in the context menu month and day are still inverted.

Any hints?

[Vasil]

Hi Massimiliano,

The values in the filter picker (not this in the context menu) are populated server side. The only reason they to be wrongly formatted is that the culture of the picker is not set server side.
Could you confirm that you still set the Culture for the whole page, not only for the grid?

Regards,
Vasil
Telerik

[Massimiliano]

Ok i hope this will clear things up... I prepared 2 screenshots.
At the top of both screenshot you can see a label wich reads current culture settings for the whole thread and for the grid. 
As you can see the setting is correctly expressed as "it-IT" wich means date format is dd-MM-yyyy.

In this first screenshot you see what happens if I pick a date and apply the filtering from the column chosing all dates < September, 6 2013
http://www.hakkar.it/test1.jpg
As you can see if I open the context menu date is inverted, so locale settings are ignored

In this second screenshot you see what happens if I pick a date and apply the filtering from the context menu, chosing again all dates < September, 6 2013
http://www.hakkar.it/test2.jpg
In this case everything is displayed correctly.

So the problem is JUST in the context menu and when filtering happens from OUTSIDE of it.
Also note that the behaviour report down here happens if I add  EnableScriptGlobalization="true" to the script manager. If I omit this one, even the second scenario fails and date inside the context menu always appear inverted, regardless of where the actual filtering happened. So adding that property gave a benefit but ONLY when filtering starts from inside the context menu.

Thanks in advance for your support.

[Vasil]

Hello Massimiliano,

I tested the behaviour in modified version of this demo, the only differences in my local project are that IsFilterItemExpanded is true and culture is set to Italian in the InitializeCulture and it is working for both the header context menu and direct filtering.

You can find the demo in your installation folder and modify it. Also please note that in the previous version of our controls I remember that there was similar problem that was fixed, so please try with the latest version if you continue to have problems in your current project.

Regards,
Vasil
Telerik

[Massimiliano]

Thank you Vasil, I will try it asap and report back. With "latest version" you mean internal builds?

[Vasil]

Hi Massimiliano,

Yes I mean with the latest internal build. Our next Beta will be publicly available in a week.

Regards,
Vasil
Telerik

[Massimiliano]

Sorry for late reply but I'm not working actively on those test lately.
Anyway I had the time to test but result is the same as described above. 
I guess this should be filed as a RadGrid localization bug at this point?

[Vasil]

Hi Massimiliano,

In order to log it as bug, we at least have to be able to replicate it. But when I did the already discussed configuration to an existing demo it worked correct on my end.

Could you send us runnable page in which the issue can be tested?

Regards,
Vasil
Telerik

[Massimiliano]

It's almost impossible for me now to "extract" the actual grid from the underlying code structure but I remember I tryed this on a clean empty project and simple grid and had the same behaviour. I will try to recreate this on an empty project and send you the page.
Could it be that my OS is set in italian as well? (gg/MM/yyyy) In any case if the localization is well handles it should be indipendent from the OS of course. Just thinking... 

[Massimiliano]

I created a single page basic grid test:
Grab zip here
Nothing special here, just the culture set to IT-it and EnableScriptGlobalization="true" on the script manager.
I get data from my DB but you can easily supply fake dates (where day <= 12 of course) to test it.

Behaviour is always the same:
- In the column textbox everything is displayed fine alwyas
- If I lanuch the filtering from the headercontext menu, and only with EnableScriptGlobalization="true" (otherwise it's wrong), everything is displayed correctly
- If I launch the filtering from the column textbox (even with EnableScriptGlobalization="true") and I then open the headercontext menu, here the date displayed in the filter box is inverted with MM/dd instead of dd/MM 

Just look at the screenshots I posted above to get this even more clear. I can make a short video also if you need it.

[Vasil]

Hello Massimiliano,

I am unable to download your archive, it shows me that it is not longer accessible.

It is a bit depended on the OS settings, since the exact code that populates the value in the context menu is:

var date = Date.parseLocale(currentFilterValue);
if (!date)
{
    try
    {
        date = new Date(currentFilterValue);
    }
    catch (e)
    {
    }
}
if (!isNaN(date) && date != null && typeof (date) != 'undefined')
{
    idGenHelper.FirstFilterValueControl.set_selectedDate(date);
}

If parseLocale fails for some reason, the date will be parsed using the culture settings of your browser and the Thread in which the JavaScript runs.
You could actually test this method in the Console of your browser to see what is returning.

Regards,
Vasil
Telerik

[Massimiliano]

I'm so ashamed Vasil.. I did some ftp cleaning and forgot that the file was referenced here.
Now is back on-line again you can download whenever you want. It's just a single page with simple grid.

I will try your code also and report back, anyway I guess parseLocale should not fail if everything is working correctly or there should be some kind of "failover" system to avoid resortingt to local os settings.

[Vasil]

Hello Massimiliano,

Do you use Windows 8 or Windows 7?

I debugged the project, and saw the issue only in Windows 8. It appears that after the filtering, when an internal collection called filter values of RadGrid is updated, the DateTime like 05/06/1996 is cast to string it goes like "05/06/1996 00.00.00" and later the Date.parseLocale("05/06/1996 00.00.00") returns null.

It seems to be some incompatibility between the server .toString and client parseLocale when an Italian culture is used. The both methods are part of the Microsoft framework, and we can not change them.

However, you could override the parse function as the code below and it should start working correct.

<telerik:RadScriptBlock runat="server">
    <script type="text/javascript">
        parseLocaleOriginal = Date.parseLocale;
        Date.parseLocale = function (val) {
            return parseLocaleOriginal(val.replace("00.00.00", ""));
        }
    </script>
</telerik:RadScriptBlock>

This is particular case for the IT culture. I could not guarantee that their scripts are working correct for other cultures. You could report it to forums.asp.net to see the official opinion on this subject.

Regards,
Vasil
Telerik

[Massimiliano]

Hallo Vasil,
first thanks again for your support. No I'm on Windows 7 64bit at the moment with italian locale.
I tryed your script (at the bottom of the page) but didn't solve:

parseLocaleOriginal = Date.parseLocale;
Date.parseLocale = function (val) {
    return parseLocaleOriginal(val.replace("00.00.00", ""));
}

Should I put this in a specific order in the page for it to work?

Also there is something that still doesn't convince me... If you look at the issue I reported in the post where I provided screenshots, enabling  EnableScriptGlobalization="true" in the script manager, triggers an odd behaviour, so that when I "launch" the filter from the header context menu, everything is displayed correctly, while if I launch the filter from the column, in the header context menu dd/MM are inverted.
Why there is this inconsistency based on "from where the filtering is started". It should always display inverted dd/MM. 
Infact if I remove EnableScriptGlobalization="true" from the script manager, the date is always inverted, while if I enable it, it's inverted only when launched from the column. 
I think there is some "wrong" threatment of the data somewhere in the grid/contextmenu logic maybe or at least something I think should be handled at control level rather than resorting to "tricks" for each locale scenario?

[Vasil]

Hi Massimiliano,

This code should be placed just under the declaration of your RadScriptManager, or above the declaration of your RadGrid.

The difference is that when you enter the value directly in the header. It is inside the RadDateInput that is located there. It's value persist during the postback, and when you open the header context menu, the value from DateInput is used for populating the picker in the context menu. And this happens client side.

When you filter using the context menu. The value is send to server, the the grid filter, then parses the values and send them to a collection of filter values, then later is used for populating the DateInputs in the Filter menu and this happen server side.

The path is different, and in the first one the value does not relates to the .ToString server side.

Regards,
Vasil
Telerik

[Massimiliano]

Hallo Vasil. Thanks for the explanation. 
I tryed the script BEFORE the grid but with no luck :(
Anyway don't you think all those tricks/workaround/exploits should be handled natively by the grid control to give consistency being culture indipendent?
We can not call it a bug, give another name, but I guess the inconsistency between what's showed in the column filter and what's in the context menu filter is still an anomaly that should be taken care of by the RadGrid control internally.

[Vasil]

Hello Massimiliano,

I can agree that it is not consistent .
Even if it works correct for most of the cultures, and the problem is not in our method, we will try to build in internally a hack for handling this case or we will use another approach that does not relays to the culture ToString server side cast.
We will do our best to improve this behavior for our next release.

Regards,
Vasil
Telerik

[Massimiliano]

Hallo Vasil, thank you for your reply. I agree that this is the best path to follow.
Glad to be helpful in finding culprits now and then ;)

[Andrea]

We are in 2016.... I'm italian and I have same Massimiliano's BUG . I'm using 2015.3.1201.40 .

What's the solution?

 

Best Regards

[Andrea]

Ops.... we are in 2017 .

I filter by 21/09/2016 and the Filter panel in header rearranges in 09/09/2017

 

Please, give me good news.

 

 

[Vasil]

Hello Andrea,

There were various of fixes targeting the formatting of the dates into the menu. At this point, if you have set culture to the whole page, it should work correctly.

If you share an example page, web.config and tell us what exactly are the culture settings in your machine, and the server, we could check your case further.

Regards,
Vasil
Telerik by Progress