I found this issue as I was working on a bug with globalization. I debugged into the the client side code and noticed the mask format was incorrect and was breaking what the client side code is expecting. This is the fix I implemented to ensure the server sets the correct pattern based on the enum type. The problem was that the enum type NAME was being assigned and this is incorrect because the name is NOT using the patter expected by the client side.
In the AjaxControlToolkit.MaskedEditValidator, the following fixes were applied in OnPreRender (the commented line is the original):
case MaskedEditType.DateTime:
...
//AttibFmt = (MaskExt.UserDateFormat == MaskedEditUserDateFormat.None ? AttibFmt : MaskExt.UserDateFormat.ToString());
AttibFmt = (MaskExt.UserDateFormat == MaskedEditUserDateFormat.None ? AttibFmt : ConvertUserDateFormat(MaskExt.UserDateFormat));
...
case MaskedEditType.Date:
...
//AttibFmt = (MaskExt.UserDateFormat == MaskedEditUserDateFormat.None ? AttibFmt : MaskExt.UserDateFormat.ToString());
AttibFmt = (MaskExt.UserDateFormat == MaskedEditUserDateFormat.None ? AttibFmt : ConvertUserDateFormat(MaskExt.UserDateFormat));
Added the following helper method to provide the correct pattern expected on the client side based on the enum type:
/// <summary>
/// Helper to fix bug that was returning the enumerated full name rather
/// than the 3-letter format causing the JavaScript functions relying on
/// the 3-letter format to fail
/// </summary>
/// <param name="enumFormat">The MaskedEditUserDateFormat type</param>
/// <returns>Returns the 3-letter representation of the enumerated type</returns>
protected string ConvertUserDateFormat(MaskedEditUserDateFormat enumFormat)
{
switch (enumFormat)
{
case MaskedEditUserDateFormat.DayMonthYear:
return "DMY";
case MaskedEditUserDateFormat.DayYearMonth:
return "DYM";
case MaskedEditUserDateFormat.MonthDayYear:
return "MDY";
case MaskedEditUserDateFormat.MonthYearDay:
return "MYD";
case MaskedEditUserDateFormat.YearDayMonth:
return "YDM";
case MaskedEditUserDateFormat.YearMonthDay:
return "YMD";
}
return "MDY";
}
I've attached the modified file. You can search on "AY PRISM fix" to find the modified code.
Comments: Please upgrade to the latest version of AJAX Control Toolkit v15.1. If the problem remains, feel free to post a new issue.
In the AjaxControlToolkit.MaskedEditValidator, the following fixes were applied in OnPreRender (the commented line is the original):
case MaskedEditType.DateTime:
...
//AttibFmt = (MaskExt.UserDateFormat == MaskedEditUserDateFormat.None ? AttibFmt : MaskExt.UserDateFormat.ToString());
AttibFmt = (MaskExt.UserDateFormat == MaskedEditUserDateFormat.None ? AttibFmt : ConvertUserDateFormat(MaskExt.UserDateFormat));
...
case MaskedEditType.Date:
...
//AttibFmt = (MaskExt.UserDateFormat == MaskedEditUserDateFormat.None ? AttibFmt : MaskExt.UserDateFormat.ToString());
AttibFmt = (MaskExt.UserDateFormat == MaskedEditUserDateFormat.None ? AttibFmt : ConvertUserDateFormat(MaskExt.UserDateFormat));
Added the following helper method to provide the correct pattern expected on the client side based on the enum type:
/// <summary>
/// Helper to fix bug that was returning the enumerated full name rather
/// than the 3-letter format causing the JavaScript functions relying on
/// the 3-letter format to fail
/// </summary>
/// <param name="enumFormat">The MaskedEditUserDateFormat type</param>
/// <returns>Returns the 3-letter representation of the enumerated type</returns>
protected string ConvertUserDateFormat(MaskedEditUserDateFormat enumFormat)
{
switch (enumFormat)
{
case MaskedEditUserDateFormat.DayMonthYear:
return "DMY";
case MaskedEditUserDateFormat.DayYearMonth:
return "DYM";
case MaskedEditUserDateFormat.MonthDayYear:
return "MDY";
case MaskedEditUserDateFormat.MonthYearDay:
return "MYD";
case MaskedEditUserDateFormat.YearDayMonth:
return "YDM";
case MaskedEditUserDateFormat.YearMonthDay:
return "YMD";
}
return "MDY";
}
I've attached the modified file. You can search on "AY PRISM fix" to find the modified code.
Comments: Please upgrade to the latest version of AJAX Control Toolkit v15.1. If the problem remains, feel free to post a new issue.