Even though this is marked as fixed in version 11.2.0 of the iGrid.NET control (point 11 of v11.2.0 | 2024-Mar-12 (Release) ), you still hear a “Ding” when you select an item from the drop-down list with ENTER
Control version used: 11.2.5

We can't reproduce that and need sample demonstrating the issue.

Hello,
I've finally been able to identify the source of the problem.

The sound is played if a call is made to Application.DoEvents() in the AfterCommitEdit event.

You will find an example application in the attachment.  WinFormsApp1.zip (6kb) downloaded 153 time(s).

To hear the sound, simply enter a value in the first cell of the grid and press the ‘Enter’ key.

Yes, you are right. But why do you call Application.DoEvents() from the AfterCommitEdit event handler? I am not sure that placing this call in event handlers of the AfterCommitEdit event is a good idea. Theoretically this call can break the normal sequence of events in WinForms, including the validation logic based on the Validating event and used in iGrid, and the result can be unpredictable.

I also asked the Claude AI about this. Below is the answer.

Calling Application.DoEvents() from a Validating event handler can cause several serious problems due to reentrancy and timing issues. Here are the main concerns:

Reentrancy Problems
Multiple validation cycles: DoEvents() processes pending Windows messages, which could trigger another focus change event while you're still in the middle of handling the current Validating event. This can lead to the same Validating handler being called recursively before the first call completes.
Stack overflow risk: In worst-case scenarios, this reentrancy could create an infinite loop where validation keeps triggering more validation, eventually causing a stack overflow exception.

Focus Management Issues
Disrupted focus flow: The Validating event is part of WinForms' focus management system. Calling DoEvents() can interfere with the normal sequence of focus events (Leave, Validating, Validated, Enter, etc.), potentially leaving the UI in an inconsistent state.
Focus stealing: Other controls or forms might unexpectedly gain focus while validation is in progress, confusing both the validation logic and the user experience.

State Consistency Problems
UI state corruption: If your validation logic depends on certain UI state (like other control values), DoEvents() might allow other events to modify that state mid-validation, leading to incorrect validation results.
Timing-dependent bugs: The validation might complete with different results depending on what other messages happen to be in the queue when DoEvents() is called.

User Experience Issues
Unexpected interactivity: Users might be able to interact with other parts of the application during validation, potentially triggering actions that shouldn't occur until validation completes.
Visual glitches: The UI might update in unexpected ways during the validation process.

Thank you, Igor, for clarifying this.
You are right, it is not a good idea to call DoEvents() when responding to a validation event.
The call to DoEvents() is only made under certain conditions in the application concerned; it is a fairly complex process.
I will modify the code to avoid calling DoEvents() when this call is triggered by an event.
Thank you for your support.