C1DateEdit migration to .NET6

Posted by: wknauf on 21 August 2022, 7:36 pm EST

    • Post Options:
    • Link

    Posted 21 August 2022, 7:36 pm EST

    Hi C1,

    I’m in the process of migrating our large app to .NET6. The only C1 component that seems to cause trouble is “C1.Win.Calendar.C1DateEdit”: The property “ValueChangedBehavior” was removed, and I think this might cause a usability problem/change for our application.

    We had subclassed C1DateEdit and set this property:

    
    this.c1DateEdit.ValueChangedBehavior = ValueChangedBehaviorEnum.FireOnAnyChange;
    
    

    This causes the “OnValueChanged” event to be triggered on any entered digit. We overrode “OnValueChanged” and didn’t forward this “ValueChanged” event to handlers but started a timer instead. If another keypress happened before the timer ticked, the timer was reset.

    So, when the user finished typing, a “ValueChanged” event was triggered automatically.

    With the new version, this feature was removed. Now, the user has to tab out of the control to trigger “ValueChanged”.

    See attached sample (contains 4.5.2 and 6.0 versions).

    C1DateEdit.zip

    Do you have any workaround to restore the old behavior?

    Best regards

    Wolfgang

  • Posted 22 August 2022, 10:14 pm EST

    Hi Wolfgang,

    We have attached the updated sample that implements similar functionality to ValueChangedBehaviorEnum.FireOnAnyChange by overriding the OnTextChanged of the C1DateEdit. Please let us know if it fits your requirements, else we can escalate it to the development team accordingly.

    C1DateEdit_Updated.zip

    Thanks, and Best Regards,

    Kartik

  • Posted 24 August 2022, 5:15 pm EST

    Thanks, this sounds promising - I could even start our timer in “OnTextChanged” instead of “OnValueChanged”. Give me some time for detailed verification - I am currently in the migration to .NET6, and it will take some time until our app starts again ;-).

    Best regards

    Wolfgang

  • Posted 1 September 2022, 1:20 am EST

    Unfortunately, I found a problem, see reworked sample:

    C1DateEdit_2022-09-01.zip

    In “Form1.cs”, “InitializeComponent”, there is this line:

    this.modifiedC1DateEdit1.CultureInfo = new System.Globalization.CultureInfo("en-US");
    

    If I remove this line (or change it to “de-DE”), the “ModifiedC1DateEdit” will raise a “TextChanged” event whenever it gets focused. I hope you can reproduce it - might depend on your localization settings.

    This is annoying, because it would trigger the “value changed” timer in our implementation.

    Any change to detect this situation and avoid it?

    Best regards

    Wolfgang

  • Posted 1 September 2022, 9:59 pm EST

    Hi Wolfgang,

    We could observe the behavior when setting the Region settings of our OS to German (Germany). We have shared all the observations and your use-case with the development team to get their insights on it. We will update you as soon as possible.

    [Internal Tracking ID: C1WIN-28107]

    Thanks, and Best Regards,

    kartik

  • Posted 19 September 2022, 6:55 pm EST

    Hi Kartik,

    any updates from the developers? Is there a workaround?

    Best regards

    Wolfgang

  • Posted 20 September 2022, 2:54 pm EST

    Hi Wolfgang,

    We are in touch with the development team to see if they can suggest a workaround. We will let you know the updates soon. Thank you for your patience.

    Best Regards,

    Kartik

  • Posted 21 November 2022, 2:21 am EST

    Hi,

    any updates on this?

    What is the ETA? Will “ValueChangedBehaviorEnum.FireOnAnyChange” be brought back or will the problem with “TextChanged” be fixed?

    We are near to releasing our .NET6 version, and as the current ValueChanged behavior is much more clumsy than the previous version, it would be good if we could tell our customers that a fix will be included in our next major version.

    Best regards

    Wolfgang

  • Posted 21 November 2022, 10:08 pm EST

    Hi Wolfgang,

    Sorry for the delay in response. Unfortunately, there is no workaround for this issue currently. We apologize for the inconvenience caused to you. As per the development team, the ETA for the “TextChanged” issue fix is the 2023v1 release.

    Thanks, and Best Regards,

    Kartik

  • Posted 21 November 2022, 10:18 pm EST

    Hi Kartik,

    any change to speed this up and add a fix to the 22v3 release?

    So, you don’t plan to bring back “ValueChangedBehaviorEnum.FireOnAnyChange”, but only fix “TextChanged” to that I can use the workaround initially suggested by our=

    Best regards

    Wolfgang

  • Posted 22 November 2022, 9:59 pm EST

    Hi Wolfgang,

    Since the builds for the 2022v3 release are already frozen and in the testing phase, we have requested the development team to see if they can include this fix in the 2022v3 hotfix release. Currently, they investigated the issue again and suggested a workaround using which you can stop the “TextChanged firing on Focus” issue by setting the “C1DateEdit.TrimEnd” property to False. We have attached the updated sample.

    Also, as per the development team, the “ValueChangedBehavior” property was backward compatible with very old versions of the C1Input and they decided not to drag this code into a new C1Input for .NET 6. Therefore, currently there are no such plans to include the “ValueChangedBehavior”. However, if you want, we can escalate an enhancement request to the development team for the same. :slight_smile:

    Attachment: C1DateEdit.zip

    Thanks, and Best Regards,

    Kartik

  • Posted 23 November 2022, 11:04 pm EST

    I can conform that the “TrimEnd” workaround works for your sample. But we use a different CustomFormat “ddd dd MMM yyyy”, and here the issue happens again.

    See attached sample C1DateEdit_2022-11-24.zip

    (I added a trace output to “OnTextChanged”).

    Maybe this is related to the issue that the displayed text changes when entering the control - see https://www.grapecity.com/forums/winforms-edition/net6-problems-in-c1dateedit-customformat-postvalidation

    Hopefully, I found another workaround: in “OnTextChanged”, I check whether the value parsed from the new text has actually changed compared to the current value of the control.

    This works for me, as in our application, I just start a timer when the user edits the C1DateEdit. The “ValueChanged” event is then raised when the timer ticks. So, I start the timer only on “real” changes.

        protected override void OnTextChanged(EventArgs e)
        {
          base.OnTextChanged(e);
          if (ParseContent(out object parsedValue, ErrorInfo) == ErrorReason.None)
          {
            if (DateTime.Equals(parsedValue, this.Value) == false)
            {
              //Start timer...
            }
          }
        }

    Best regards

    Wolfgang

  • Posted 24 November 2022, 1:43 am EST

    So, there is a new code sample that hopefully restores the behavior that we had with the old version: when text is typed, a timer starts and on tick the “ValueChanged” event is raised. “ValueChanged” is also raised when the CalendarDropDown or the spin buttons are used.

    It is not a good idea to set the “Value” of the picker in “OnTextChanged” - this might confuse the focus in the textbox while typing. So I moved it to the timer tick.

    But I need your help with one issue: in the timer tick, I restore the previous textbox selection. But this does not work as expected.

    To reproduce:

    a) type the day part (e.g. “20”). The cursor moves to the month part.

    b) wait a short period until my timer ticks. Selection still seems to be at the month section, but…

    c) type a month digit. It is entered in the day section.

    C1DateEdit_WithTimer.zip

    Do you have an idea how to work around this?

    Best regards and many thanks for your support up to now!

    Wolfgang

  • Posted 24 November 2022, 11:17 pm EST

    Hi Wolfgang,

    Thank you for providing the sample and detailed information. Unfortunately, we could not find a way to work around this behavior. We have shared this with the development team to see if they can suggest something useful. We will let you know as soon as possible. We apologize for all the inconvenience caused to you.

    Best Regards,

    Kartik

  • Posted 28 November 2022, 7:43 pm EST

    Hi Wolfgang,

    As per the development team, the main problem with using “SelectionStart” is that in addition to the external selection, there is also an internal selection for the Input, which users cannot influence. The only possible way to influence it at the moment is to click by the mouse. Currently, the developers have suggested a workaround by using reflection, to stimulate a mouse click and refresh the selection. Please refer to the updated sample.

    Also, for further actions:

    1. The development team will adjust the control so that the internal selection for the Input reflects “SelectionStart” and they will also expand the public API so that the user has more opportunities to influence the selection.

    2. As per the development team, the “TextChanged firing” behavior (on getting and losing Focus) reported earlier is not a bug and should be avoided by setting the “TrimEnd = False”.

    The issue you are facing even after setting the TrimEnd property is due to the bug reported in (https://www.grapecity.com/forums/winforms-edition/net6-problems-in-c1dateedit-customformat-postvalidation) and will be fixed.

    1. Since all the above changes will need adding a new public API, the developers will not be able to add it in the 2022v3 hotfix release and ETA for the fix is the 2023v1 release.

    2. If you want, please let us know and we will escalate a feature request for the “ValueChangedBehavior” to the development team.

    Attachment: C1DateEdit_WithTimer_Workaround.zip

    Thanks, and Best Regards,

    Kartik

  • Posted 28 November 2022, 8:41 pm EST

    Great, the MouseClick workaround works fine.

    No need for reintroducing the “ValueChangedBehavior” - I have a working solution now. I prefer the “OnTextChanged” code over the “ValueChangedBehavior” solution ;-).

    So, “TrimEnd” will still be needed with the new version so that the “OnTextChanged” is not fired when the control receives focus?

    Best regards

    Wolfgang

  • Posted 28 November 2022, 9:43 pm EST

    Hi Wolfgang,

    Yes, as per the dev team, the “TrimEnd” will be needed to avoid the “OnTextChanged” on focus.

    Best Regards,

    Kartik

  • Posted 5 January 2023, 7:53 pm EST

    I assume this change in .588 is not related to this issue?

    [DateEdit][NET6] Text of C1DateEdit was set when clicking on it for the first time even if EmptyAsNull=true. (Jira:C1WIN-28155)

    Best regards

    Wolfgang

  • Posted 5 January 2023, 8:14 pm EST

    Hi Wolfgang,

    Yes, the change you have mentioned is not related to this issue. The ETA for this issue fix is the 2023v1 release.

    Kind Regards,

    Kartik

  • Posted 11 April 2023, 8:55 pm EST

    I can confirm that the fix for SelectionStart/SelectionEnd is contained in .596 and works in my sample:

    [DateEdit][NET6] Date time input selection did not reflect SelectionStart SelectionLength properties. (Jira:C1WIN-28107)

    Best regards

    Wolfgang

  • Posted 11 April 2023, 10:07 pm EST

    Hi Wolfgang,

    Thank you for the confirmation, and please accept my apologies for not responding sooner to update you on the fix.

    Kind Regards,

    Kartik

Need extra support?

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

Learn More

Forum Channels