Fix DataGridViewComboBoxCell setting incorrect value when DisplayMember values are duplicated

[abineshPalanisamy]

Fixes #11311

Proposed changes

• Update DataGridViewComboBoxCell.LookupValue to prefer the actual selected item from the active editing ComboBox when the cell is in edit mode.
• Avoid ambiguous reverse lookups based on DisplayMember when multiple data source items share the same display value.
• Preserve existing behavior for non-edit scenarios or when no selected item is available by retaining the current lookup logic as a fallback.

Root cause

• DataGridViewComboBoxCell.LookupValue resolves the committed value by performing a reverse lookup using the DisplayMember (display text).
• When multiple items share identical DisplayMember values, this lookup becomes ambiguous.
• The current implementation performs a linear scan of the data source and returns the first matching item, rather than the item actually selected by the user.
• As a result:
  • The committed value may not correspond to the selected item.
  • Dependent columns (such as IDs or computed values) remain aligned with the first matching entry instead of the user’s selection.

Customer Impact

• Fixes incorrect commit behavior in DataGridViewComboBoxCell when multiple items share the same DisplayMember text.
• Ensures dependent values (for example, bound Id fields or computed columns derived from the selected item) are updated from the item the user actually selected instead of the first matching display-text entry.

Regression?

• No

Risk

• Low to medium.
• The change is limited to the edit-commit path and only affects scenarios where the cell owns the active editing ComboBox.
• Existing lookup behavior is preserved as a fallback when there is no active editing control or no selected item is available.

Screenshots

Before

Combo_box.before.fix.mp4

After

Combo_box.fix.mp4

Test methodology

• Reproduced the issue using a DataGridViewComboBoxCell bound to multiple items with identical DisplayMember values and distinct underlying values.
• Verified that selecting the second or third duplicate display entry now commits the correct underlying item instead of resolving to the first matching item.
• Verified that dependent columns (for example, Id or derived/computed values) update correctly after commit.
• Verified that existing behavior remains unchanged for scenarios with unique DisplayMember values.
• Reviewed and executed existing unit test cases to ensure no regressions were introduced.

Accessibility testing

Test environment(s)

• 11.0.100-preview.3.26170.106

Microsoft Reviewers: Open in CodeFlow

[KlausLoeffelmann]

Thanks for taking this initiative!

But we need to vet these kinds of bug fixes more carefully.
Please always consider, that there Billions of deployed WinForms App instances out there, which customers are working with.

So, this is, why are want you to ask to do the following:

• Could you provide a .NET Framework app, which corrected this bug with an internal workaround.
• Port this App to .NET 11.
• Run it, while your fix is in place.

What's its behavior?

[KlausLoeffelmann]

So, I was thinking.

It is important, to get these bugs fixed.
It is more important, to not break the world.

(And this a general issue, we need to address, so I will publish a literal issue, to raise awareness to this more directly.)

I had a concept in mind, actually for a bit, to find an approach to do the one without risking the other. I think, there can be a good solution for this.

So - I would like to suggest this to you, before we are blindly rushing into fixing APIs, which I would then need to reject because the breaking changings risk would be too large.

Let's do it in close rooms, and the merge the best of both worlds later, to get an optimum of coverage.

My ask:
Brainstorm a concept, which would be:

• Mitigate those issues in principle, or, more clearly:
  Find a way, that can fix those old, long-standing bugs, but without breaking the workarounds, which our customers might have found in the meanwhile.
• Do it in a way, which always make this mitigation intrinsically transparent to an AI Code Assistants or Generative Code Completion tools.

Why the latter? Because we CANNOT AT ALL risk, that when those AI Code Assistants or Generative Code Completion tools do more or less big migration efforts effectively autonomously, no one will catch the bugs, which will be introduced, because the earlier necessary bug-workaround/mitigation WILL be migrated along, and then BECOME the bug, that will make a software become unstable, crash, or - even worse - lead in a fictional scenario, let the plutonium rods in an Atomic Power Station melt, when the power station service provider rolled out the new version, which was migrated from NetFX 4.7.2 to .NET 11... 😉