[.NET6] [C1DateEdit] "AcceptsEscape" not working, "AcceptsEnter" missing

Posted by: wknauf on 17 October 2023, 8:45 pm EST

  • Posted 17 October 2023, 8:45 pm EST

    Hi C1,

    see attached sample:

    C1DateEditEnter.zip

    I have a C1DateEdit on a modal dialog.

    When pressing “Escape” while C1DateEdit is focused, I would expect the dialog to close with DialogResult = “Cancel”.

    When pressing “Enter”, the same should happen with Dialog = “OK”.

    C1DateEdit has a property “AcceptsEscape”, but it does not seem to work.

    And a property “AcceptsEnter” is missing.

    I tried to achieve this by handling “C1DateEdit.KeyPress”. But this does not work very well, because:

    a) when pressing “Escape” while having typed a partial date part (e.g. “19” in the year field), I would expect it to cancel the editing process and stay in the dialog. The second “Escape” then should close the dialog.

    b) same for “Enter” with a partial input: the “Value” of C1DateEdit is not updated properly, and thus “C1DateEdit.Value” still returns the date before starting editing.

    The ENTER issue could be worked around by calling “UpdateValueWithCurrentText”. But for the “Escape” issue I have no workaround - there is no property to detect that C1DateEdit is still in edit mode:

    Here is a possible code to apply those keys:

        private void c1DateEdit1_KeyPress(object sender, KeyPressEventArgs e)
        {
          if (e.KeyChar == 13)
          {
            //ENTER:
            if (this.c1DateEdit1.UpdateValueWithCurrentText() == false)
            {
              MessageBox.Show(this, "ENTER canceled - could not update text to value: " + this.c1DateEdit1.Value);
              this.buttonOK.PerformClick();
            }
            else
            {
              MessageBox.Show(this, "ENTER: " + this.c1DateEdit1.Value);
              this.buttonOK.PerformClick();
            }
          }
          else if (e.KeyChar == 27)
          {
            //ESCAPE:
            //TODO: first "Escape" should cancel an unfinished editing...
            MessageBox.Show(this, "ESCAPE: " + this.c1DateEdit1.Value);
            this.buttonCancel.PerformClick();
          }
        }

    We got a user bugreport that in small “Go to date” dialog of ours ENTER does not close the dialog. This brought me to this issue.

    Would be great if you could add a property “AcceptsEnter” to C1DateEdit. And the bonus would be to fix “AcceptsEscape” ;-).

    Best regards

    Wolfgang

  • Posted 17 October 2023, 9:17 pm EST

    Update: my workaround for “Enter” is not really good, because the “ValueChanged” event of the picker is not raised. This would require probably an API enhancement? “UpdateValueWithCurrentText” does not fire this event.

  • Posted 18 October 2023, 8:56 pm EST

    Hello Wolfgang,

    About the AcceptsEscape = false, we have reported this to the developers to look into this matter.

    [Internal Tracking ID: C1WIN-31247]

    We have handled the ValueChanged event, and when pressing Enter, the control shifts to it. Are there any specific steps to reduce your mentioned behavior?

    Regards,

    Prabhat Sharma.

  • Posted 19 October 2023, 7:56 am EST - Updated 19 October 2023, 8:02 am EST

    Hi Prabhat,

    about the “Enter” behavior:

    Just a general remark: When you add a winforms DateTimePicker to the dialog in my sample, it closes the dialog when ENTER is pressed. This does not happen with C1DateEdit. But the winforms picker also has the same problem that “ValueChanged” is raised AFTER enter is handled - so you have the chance to be better :wink:

    And now to the issue with my current workaround to call “UpdateValueWithCurrentText”: in my sample, the click event for the “OK” button is called before “ValueChanged” is fired. Attached is a reworked sample. I added code to “OK” click to keep the form open when a year smaller then 2023 is entered.

    C1DateEditEnter_2023-10-19.zip

    So, type “21” (don’t complete editing the year field!), and press enter.

    There is a messagebox sequence that demonstrates that first the OK button click is handled (messagebox “Invalid year”), then the “ValueChanged” is fired.

    In our real app, we have at least one form where other controls are updated after a C1DateEdit value change. As part of the “OK” click, the form is validated, and if the C1DateEdit “ValueChanged” event was not fired, there might be input errors due to controls not being updated based on the new C1DateEdit value. Those errors would be fixed in “ValueChanged”.

    While writing this post and doing more testing, I thought I found a workaround for us: We have subclassed C1DateEdit. And we handle “OnTextChanged” and use a timer to fire “ValueChanged” events while the user is editing inside the control (you might remember a lot of posts from me ;-)). So, I can detect whether the control is in EditMode by checking whether the timer is running.

    My workaround could look like this:

       protected override void OnKeyPress(KeyPressEventArgs e)
       {
         if (e.KeyChar == 13)
         {
           //ENTER:
           bool canContinue = true;
           if (this.timer.Enabled == true)
           {
             if (this.UpdateValueWithCurrentText() == false)
             {
               //Enter canceled:
               canContinue = false;
             }
             else
             {
               this.OnValueChanged(EventArgs.Empty);
             }
           }
           if (canContinue == true)
           {
             //Click OK button
           }
           e.Handled = true;
           //Don't call "base.OnKeyPress"
         }
         else if (e.KeyChar == 27)
         {
           //ESCAPE: TODO...
           base.OnKeyPress(e);
         }
         else
         {
           base.OnKeyPress(e);
         }
       }
    

    But this does not work perfectly: in my sample, “OnValueChanged” is raised another time in base class code when the text was changed:

    I give up for now - it is late. I fear you want a full sample the reproduces this problem ;-). But not today…

    Best regards

    Wolfgang

  • Posted 20 October 2023, 5:22 am EST

    Attached is a reworked sample with the edit timer based on https://www.grapecity.com/forums/winforms-edition/c1dateedit-migration-to-net6

    C1DateEditEnter_2023-10-20.zip

    Click the button “Show modified C1DateEdit dialog”, then enter “2021” in the year field and press ENTER before the timer ticks.

    I show a messagebox whenever “ValueChanged” is fired. You will see that it is first fired because of my call to “this.OnValueChanged”, then “OnKeyPress” performs a click on the “OK” button (which cancels closing of the dialog, as I reject dates before 2023). And after this, another “ValueChanged” event is fired by C1DateEdit (see screenshot in previous post).

    I don’t have an idea on how to prevent this. So it is up to your developers to check this - would be best if C1DateEdit could handle the “ENTER” key itself. The control would have to update its value it if is in edit mode.

    If this behavior will be added, I would probably still have to handle “OnKeyPress” and cancel my timer.

    And it would be good to handle “ESCAPE”, which should first cancel an uncommitted editing, and next ESCAPE key press should click the forms Cancel button.

    Hope my post contains all necessary information.

    Best regards

    Wolfgang

    And I noticed the the subject of this post is a bit wrong: “AcceptsEnter” = TRUE in winforms textboxes is used to control whether a multiline textbox handles ENTER to insert newlines in the text content. There is no way to switch off the behavior to click the Accept button of the parent form.

  • Posted 22 October 2023, 5:46 pm EST

    Hello Wolfgang,

    Thank you for your detailed feedback and comments.

    We have raised this concern to the development team and will let you know as soon as we get any update on this.

    [Internal Tracking ID: C1WIN-31247]

    In case, the devs revert back and need any additional information, I will revert back to you.

    Regards,

    Prabhat Sharma

  • Posted 24 October 2023, 10:06 pm EST - Updated 24 October 2023, 10:11 pm EST

    Hello Wolfgang,

    The developer has shared the attached image and asking if this is the expected behavior, you are looking for.

    Please confirm so that we can pass this information to the developer.

    Regards,

    Prabhat Sharma.

  • Posted 25 October 2023, 6:28 pm EST - Updated 25 October 2023, 6:33 pm EST

    Hi Prabhat,

    it seems the developers modified my sample a bit, as the textbox logging is not the same as in my initial sample. I updated my sample so that event handlers also log to the textbox, and hope that I did the same changes as your developers.

    C1DateEditEnter_2023-10-26.zip

    With my version, I observe the behavior that after the “OK”, another “ValueChanged” is fired:

    The screenshot from the developers seems to be correct.

    Did they make changes to C1DateEdit? If yes: will the control support the ENTER key out of the box, or do I need my workaround?

    Best regards

    Wolfgang

  • Posted 26 October 2023, 5:44 pm EST

    Hello Wolfgang,

    Thank you for your comments.

    We have forwarded this to the developers and will let you know whether you need to apply any workaround or if will they make any changes in the API for this.

    Regards,

    Prabhat Sharma.

  • Posted 31 October 2023, 11:13 pm EST

    Hello Wolfgang,

    The developers have shared a workaround to achieve your requirement, please go through it and let us know if it helps.

    Regards,

    Prabhat Sharma.

    TestSample.zip

  • Posted 1 November 2023, 7:05 am EST

    Amazing, this works! I don’t understand why, because “AcceptsEnter” should only be supported in multiline textboxes and should not have any special effect in singleline boxes ;-).

    So, the workaround in my C1DateEdit subclass will be this to handle ENTER and ESCAPE (the latter is only fired in “OnKeyUp”, but not in “OnKeyPress”, as I wrote in my initial question):

        protected override void OnControlAdded(ControlEventArgs e)
        {
          base.OnControlAdded(e);
          var textBox = (TextBox)this.Controls[0];
          textBox.AcceptsReturn = true;
        }
        
        protected override void OnKeyUp(KeyEventArgs e)
        {
          if (e.KeyCode == Keys.Escape)
          {
            //ESCAPE: 
            base.OnKeyUp(e);
            //Click the Cancel button:
            this.FindForm().CancelButton?.PerformClick();
          }
          else
          {
            base.OnKeyUp(e);
          }
        }

    Could you confirm whether this is correct?

    Are there plans from the devs to support this out of the box? If yes, I could remove my workarounds in the future.

    Best regards

    Wolfgang

  • Posted 1 November 2023, 7:31 pm EST

    Hello Wolfgang,

    We have forwarded this to the developers and will let you know as soon as we get the update from their end.

    Regards,

    Prabhat Sharma.

  • Posted 2 November 2023, 4:20 pm EST

    Hello Wolfgang,

    Please find the developer comment on the case:

    >> Are there plans from the devs to support this out of the box? If yes, I could remove my workarounds in the future.

    Yes, as per devs, current behavior is a bug, and they will fix it in the 2024v1 release.

    Could you confirm whether this is correct?

    Looks fine, you can try to use c1DateEdit1.AcceptsEscape = false; to support Esc by dialog form.

    Regards,

    Prabhat Sharma.

  • Posted 3 November 2023, 12:07 am EST

    Hi Prabhat,

    Nope, this has no effect (see my initial post :wink: ).

    Best regards

    Wolfgang

  • Posted 5 November 2023, 1:59 pm EST

    Hello Wolfgang,

    Of course how can I forgot.

    >>Looks fine, you can try to use c1DateEdit1.AcceptsEscape = false; to support Esc by dialog form.

    The developers have verified it as a bug and will fix this soon.

    Regards,

    Prabhat Sharma.

  • Posted 27 January 2024, 2:42 am EST

    Seems both issues were fixed in .636 - though the JIRA number does not match:

    AcceptsReturn property did not work correctly. (Jira:C1WIN-31280)

    To sum it up: In order to close the modal dialog when ESCAPE is pressed in C1DateEdit, you have to set:

    c1DateEdit.AcceptsEscape = false;

    Best regards

    Wolfgang

  • Posted 28 January 2024, 5:47 pm EST

    Hello Wolfgang,

    Thanks for the confirmation.

    The ID that you see is the Jira ticket created by the developers internally for this specific issue, as there are multiple scenarios in Jira case C1WIN-31264.

    Regards,

    Prabhat Sharma.

Need extra support?

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

Learn More

Forum Channels