C1DateEdit value is not applied if dialog is committed with ENTER

C1DateEdit value is not applied if dialog is committed with ENTER

Posted by: wknauf on 12 May 2026, 4:22 am EST

• 

  wknauf

  • Post Options:
  • Link
    Copy
  • Jump To Answer

  Posted 12 May 2026, 4:22 am EST

  This is a regression in .755 (.NET 9), see attached sample: a C1DateEdit control is placed on a modal dialog that has a “OK” button. Edit the C1DateEdit value and change e.g. the day part by typing. Now press the ENTER key (without moving the focus to another control).
  
  The dialog is committed, but the new input is not applied to the C1DateEdit value. The label in the main form displays the old value.
  
  C1DateEditDialog.zip

  It worked with 10.0.20252.740.

  Is this something that can be fixed on your side?

  Best regards

  Wolfgang

• 

  uttkarsh.matiyal

  

  • Post Options:
  • Link
    Copy

  Posted 12 May 2026, 9:17 am EST

  Hello Wolfgang,

  We were able to observe the behavior you described, where pressing the ENTER key without first changing focus results in the updated date being lost. It seems to us that the C1DateEdit control is currently processing the change only after the focus shifts, which is a change from the behavior seen in version v740.
  
  We are getting in touch with our development team for their insights on this . We will update you as soon as we have more information from them. [Internal Tracking ID: C1WIN-35282]
  
  In the meantime, you can manually update the value while the control still has focus by using the UpdateValueWithCurrentText() API. Here is the sample code snippet to implement this:

   c1DateEdit1.UpdateValueWithCurrentText();
   return (DateTime)this.c1DateEdit1.Value;

  We have attached the modified sample project for your reference. Please have a look at it, and if you have any other concerns, feel free to ask

  Regards,
  
  Uttkarsh.

  C1DateEditDialog__2_.zip

• 

  wknauf

  • Post Options:
  • Link
    Copy

  Posted 12 May 2026, 10:24 am EST

  Hi Uttkarsh,

  thanks for the workaround suggestion. But I think for us it will work without it. We already have a timer on our subclass of C1DateEdit that applies the value if the user waits a short time. So, most of the cases, the users will not even notice the problem.
  
  Anyway, a fix would be nice

  Best regards

  Wolfgang

• 

  uttkarsh.matiyal

  

  • Post Options:
  • Link
    Copy

  Posted 13 May 2026, 12:04 am EST

  Hello Wolfgang,

  Sure, we’ll update you once we have more insights from the development team.

  Regards,
  
  Uttkarsh.

• 

  uttkarsh.matiyal

  

  • Post Options:
  • Link
    Copy

  Posted 14 May 2026, 12:19 am EST

  Hello Wolfgang,

  As per the team, the reported issue is a bug. [Bug Tracking ID: C1WIN-35292]
  
  We’ll update you once the fix is available.

  Regards,
  
  Uttkarsh.

• 

  wknauf

  • Post Options:
  • Link
    Copy

  Posted 13 July 2026, 4:29 am EST

  I think this was fixed in .796 - at least my sample works now.

  The readme entry for the issue id is a bit confusing:

  Components based on text editors didn’t handle focus state correctly when first initialized. (Jira:C1WIN-35292, C1WIN-35115)

  Best regards

  Wolfgang

• 

  uttkarsh.matiyal

  

  • Post Options:
  • Link
    Copy

  Posted 13 July 2026, 4:58 am EST

  Hello Wolfgang,

  Glad to hear that build .796 resolves the issue on your end, and thanks for pointing out the readme wording.
  
  The C1WIN-35292 (the ENTER/modal dialog issue you originally reported) and C1WIN-35115 (a related issue where text-editor-based controls didn’t handle focus state correctly on initial load) shared the same root cause, so they were fixed together and verified in internal builds 791 and 792 respectively, both shipped as part of 2026 v1 hotfix 1. The readme entry lists both IDs under a single generic line since the underlying fix was common to both; that’s why the phrasing reads a bit broadly rather than being specific to your ENTER-key scenario.

  Regards,
  
  Uttkarsh.

• 

  wknauf

  • Post Options:
  • Link
    Copy

  Posted 13 July 2026, 6:15 am EST

  No problem - as the issue id was mentioned, it was quite clear ;-). I know myself that a customer issue description and the real underlying error might not have much in common. So my comment was no complaint, just a request for clarification that the fix handles my issue.

  Many thanks

  Wolfgang