[NET6] Problems in C1DateEdit: CustomFormat, PostValidation

Posted by: wknauf on 22 November 2022, 7:11 am EST

    • Post Options:
    • Link

    Posted 22 November 2022, 7:11 am EST - Updated 22 November 2022, 7:16 am EST

    Hi C1,

    see attached sample: DateEditCustomFormat.zip

    It shows two problems:

    Problem 1: I set a CustomFormat to “ddd dd MMM yyyy”.

    Start the sample, and press the “TAB” key.

    Now, the month name is displayed wrong - instead of “Mär” it is the full month name “März”.

    Problem 2: I use “PostValidation” intervals to restrict the entered date range. But I don’t find a way to define those intervals in a way that works.

    This is from old code that worked with the .NET4.5.2 version:

          this.c1DateEdit1.PostValidation.Intervals.AddRange(new ValueInterval[] {
                new ValueInterval(new System.DateTime(1753, 1, 1, 0, 0, 0, 0), new System.DateTime(9998, 12, 30, 0, 0, 0, 0), true, true)});

    This does not work - whenever you type in a date (e.g. “31 3 2022”) and tab out of the control, a validation error is shown:

    I also tried to specify the “ValueInterval” in different string formats, but all don’t seem to work.

    How to do you do this correctly? In WinForms designer for this property, there seems to be only a textfield to specify the date value, but no hint about the format.

    Those two are rather urgent issues, as we are planning to release our .NET6 version soon, and found those issues in testing.

    I think I don’t need the PostValidation ranges, but the display issue is also a major problem.

    Best regards

    Wolfgang

  • Posted 22 November 2022, 8:18 am EST

    OK, I think I found a workaround for the validation problem.

    And by digging through the code of “PostValidation.ValidateValuesAndIntervals”, I think I also found the reason/bug in C1DateEdit: this seems to happen only on non english cultures.

    Here are the relevant code parts:

            IComparable comparable = (IComparable)Convert.ChangeType(value, ItemType, f.get_CultureInfo());
            ...
            for (int l = 0; l < Intervals.Count; l++)
            {
              ValueInterval valueInterval = Intervals[l];
              if ((!valueInterval.UseMinValue || ((!valueInterval.IncludeMin || comparable.CompareTo(valueInterval.MinValue) >= 0) && (valueInterval.IncludeMin || comparable.CompareTo(valueInterval.MinValue) > 0))) && (!valueInterval.UseMaxValue || ((!valueInterval.IncludeMax || comparable.CompareTo(valueInterval.MaxValue) <= 0) && (valueInterval.IncludeMax || comparable.CompareTo(valueInterval.MaxValue) < 0))))
              {
                return true;
              }
            }

    “Convert.ChangeType” will result in a string like “31.03.2022 00:00:00” when entering the date “31st march 2022”.

    The “MinValue” and “MaxValue” of the interval contain the strings “01.01.1753” and “30.12.9998” (when using range build from DateTime objects as done in my initial sample - in the current workaround I used string ranges in english format).

    Calling “compareTo” on those string does not work at all.

    My workaround: specify PostValidationIntervals in english format (“1753-01-01” and “9998-12-31”).

    Then register a PostValidating event:

    this.c1DateEdit1.PostValidation.Validation = C1.Win.Input.PostValidationType.PostValidatingEvent;
    this.c1DateEdit1.PostValidating += C1DateEdit1_PostValidating;

    In this event, convert the current value of the control also to english format. Now I can use the “CompareTo” code as token from your implementation:

        private void C1DateEdit1_PostValidating(object? sender, C1.Win.Input.PostValidationEventArgs e)
        {
          IComparable = ((DateTime) e.Value).ToString("yyyy-MM-dd");
          for (int l = 0; l < e.PostValidation.Intervals.Count; l++)
          {
            ValueInterval valueInterval = e.PostValidation.Intervals[l];
            if ((!valueInterval.UseMinValue || ((!valueInterval.IncludeMin || comparable.CompareTo(valueInterval.MinValue) >= 0) && (valueInterval.IncludeMin || comparable.CompareTo(valueInterval.MinValue) > 0))) && (!valueInterval.UseMaxValue || ((!valueInterval.IncludeMax || comparable.CompareTo(valueInterval.MaxValue) <= 0) && (valueInterval.IncludeMax || comparable.CompareTo(valueInterval.MaxValue) < 0))))
            {
              //OK
            }
            else
            {
              e.Succeeded = false;
            }
          }
        }
    

    See attached modified sample: DateEditCustomFormat_Modified.zip

    The rendering problem is still open.

    Best regards

    Wolfgang

  • Posted 23 November 2022, 6:06 am EST

    Hi Wolfgang,

    Thanks a lot for providing the detailed information and sample. We could see both the issues you mentioned on our end. We have reported the issues to the development team and will get back to you with the updates soon.

    [Internal Tracking ID: C1WIN-28665, C1WIN-28666]

    Best Regards,

    Kartik

  • Posted 24 November 2022, 11:06 am EST

    In my own implementation of the “PostValidation” handler, I noticed a possible problem: we use C1Edit also as time picker (custom format “HH:mm”). As the time value might be restricted, we use PostValidation intervals, and here the date part is set to a dummy value “1753/1/1”. When setting the value of the picker, we always use this date for the date part, only the time part is valid.

    But the datetime argument of the “PostValidation” callback and also “ParseContent” result use “DateTime.Today” for the date part => the date part of the “Value” of the picker is ignored.

    This caused a validation error in my code, as DateTime.Today is out of range of the PostValidation interval.

    Attached sample shows this: C1DateEditPostValidationTime.zip

    I could work around it in my own PostValidation code, but maybe you could take a look at this issue. If you fix the initial validation error, but this problem with time format is still open, I could not replace my own validation code.

    Best regards

    Wolfgang

  • Posted 25 November 2022, 4:02 am EST

    Hi Wolfgang,

    Thank you for providing the sample. We could see the behavior you explained on our end. We have reported the observations to the development team for investigation and will let you know the updates as soon as possible.

    [Internal tracking ID: C1WIN-28666]

    Best Regards,

    Kartik

  • Posted 12 April 2023, 5:53 am EST

    Hi C1,

    is there a roadmap for fixes of those two issues? A fix for the month rendering problem is more important to me.

    Best regards

    Wolfgang

  • Posted 12 April 2023, 7:03 am EST

    Hi Wolfgang,

    The fixes for both of these issues are planned to be included in the upcoming 2023v1 hotfix release. We will let you know as soon as the release is available for download. We apologize for the inconvenience caused to you.

    Best Regards,

    Kartik

  • Posted 2 June 2023, 4:47 am EST

    I can confirm that this was fixed in .603:

    [DateEdit][NET6] Incorrect text was shown when losing focus in some cultures if CusatomFormat was used. (Jira:C1WIN-28665)

    [DateEdit][NET6] Error was shown for a valid date in PostValidation for some cultures when using validation Intervals. (Jira:C1WIN-28666)

    Also the “ParseContent” problem in my additional question (https://www.grapecity.com/forums/winforms-edition/net6-problems-in-c1dateedit-customformat-postvalidation#63512) was fixed - the time picker returns the date part that I initially provided.

    Good work ;-)!

    Wolfgang

  • Posted 2 June 2023, 5:02 am EST

    Hi Wolfgang,

    Thanks a lot for the confirmation. We were testing this fix just now to let you know about it ;-).

    Best Regards,

    Kartik

  • Posted 11 July 2023, 9:33 am EST

    Just a bit of additional info about this issue:

    to resolve this: set this DateTimeStyle:

    this.c1DateEdit.ParseInfo.DateTimeStyle = base.ParseInfo.DateTimeStyle | DateTimeStyles.NoCurrentDateDefault;

    Now, the “Value” property returns “01.01.001” + time of day.

    Use DateTime.MinValue + time of day for the PostValidation intervals. Now, you can achieve a time range validation in a C1DateEdit with time format.

    Best regards

    Wolfgang

  • Posted 11 July 2023, 4:40 pm EST

    Seems the validation problems are not fully fixed: follow up for .603 is here: https://www.grapecity.com/forums/winforms-edition/net6-c1dateedit-validation-reopened

Need extra support?

Upgrade your support plan and get personal unlimited phone support with our customer engagement team

Learn More

Forum Channels