BindingNavigator control fails to insert items when clicking “Insert Standard Items” in DemoConsole application

[Philip-Wang01]

.NET version

main branch of Winforms repo

Did it work in .NET Framework?

Not tested/verified

Did it work in any of the earlier releases of .NET Core or .NET 5+?

No, this was changed after the PR #11780

Issue description

In DemoConsole test app of WinForms repo, BindingNavigator control fails to insert items when clicking “Insert Standard Items”.

testBindingNavigatorInsertStandardItems.mp4

Steps to reproduce

Test sample: DemoConsole in Winforms repo

[Tanya-Solyanik]

@ricardobossan , @Philip-Wang01 - do command links in property browser work for any other controls? If not, let's close this issue.

[Philip-Wang01]

@Tanya-Solyanik For BindingNavigator controls, only “Insert Standard Items” does not work. For most of the other controls, the command links in Property Browser work.

test12005.mp4

[ricardobossan]

Status Update

Issue Overview

The problem occurs when the "Insert Standard Items" command is clicked on the BindingNavigator control in the DemoConsole application. The issue is tied to how ToolStripSeparator names are resolved differently between InProc and Runtime.

Investigation Steps

1. Find Error and Callstack:

• The callstack and print of the error message indicate that the root cause is related to the naming resolution of ToolStripSeparator.

• Error Message:
  

• CallStack:

  System.Windows.Forms.Design.dll!System.Windows.Forms.Design.StandardMenuStripVerb.CreateStandardToolStrip(System.ComponentModel.Design.IDesignerHost host, System.Windows.Forms.ToolStrip tool) Line 361 C#

  System.Windows.Forms.Design.dll!System.Windows.Forms.Design.StandardMenuStripVerb.InsertItems() Line 55 C#
  System.Windows.Forms.Design.dll!System.Windows.Forms.Design.ToolStripActionList.InvokeInsertStandardItemsVerb() Line 128 C#
  [Lightweight Function]
  System.Private.CoreLib.dll!System.Reflection.MethodBaseInvoker.InvokeWithNoArgs(object obj, System.Reflection.BindingFlags invokeAttr) Line 87 C#
  System.Windows.Forms.Design.dll!System.ComponentModel.Design.DesignerActionMethodItem.Invoke() Line 58 C#
  System.Windows.Forms.Design.dll!System.ComponentModel.Design.DesignerActionPanel.MethodLine.OnLinkLabelLinkClicked(object sender, System.Windows.Forms.LinkLabelLinkClickedEventArgs e) Line 62 C#
  System.Windows.Forms.dll!System.Windows.Forms.LinkLabel.OnLinkClicked(System.Windows.Forms.LinkLabelLinkClickedEventArgs e) Line 957 C#
  System.Windows.Forms.dll!System.Windows.Forms.LinkLabel.OnMouseUp(System.Windows.Forms.MouseEventArgs e) Line 888 C#
  System.Windows.Forms.dll!System.Windows.Forms.Control.WmMouseUp(ref System.Windows.Forms.Message m, System.Windows.Forms.MouseButtons button, int clicks) Line 11875 C#
  System.Windows.Forms.dll!System.Windows.Forms.Control.WndProc(ref System.Windows.Forms.Message m) Line 12653 C#
  System.Windows.Forms.dll!System.Windows.Forms.Label.WndProc(ref System.Windows.Forms.Message m) Line 1449 C#
  System.Windows.Forms.dll!System.Windows.Forms.LinkLabel.WndProc(ref System.Windows.Forms.Message msg) Line 1768 C#
  System.Windows.Forms.dll!System.Windows.Forms.Control.ControlNativeWindow.OnMessage(ref System.Windows.Forms.Message m) Line 66 C#
  System.Windows.Forms.dll!System.Windows.Forms.Control.ControlNativeWindow.WndProc(ref System.Windows.Forms.Message m) Line 115 C#
  System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.Callback(Windows.Win32.Foundation.HWND hWnd, Windows.Win32.MessageId msg, Windows.Win32.Foundation.WPARAM wparam, Windows.Win32.Foundation.LPARAM lparam) Line 351 C#
  [Native to Managed Transition] > [Managed to Native Transition]
  System.Windows.Forms.dll!System.Windows.Forms.Application.LightThreadContext.FPushMessageLoop(Microsoft.Office.msoloop uReason) Line 109 C#
  System.Windows.Forms.dll!System.Windows.Forms.Application.LightThreadContext.RunMessageLoop(Microsoft.Office.msoloop reason, bool fullModal) Line 26 C#
  System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Microsoft.Office.msoloop reason, System.Windows.Forms.ApplicationContext context) Line 808 C#
  System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Microsoft.Office.msoloop reason, System.Windows.Forms.ApplicationContext context) Line 695 C#
  System.Windows.Forms.dll!System.Windows.Forms.Application.RunDialog(System.Windows.Forms.Form form) Line 1338 C#
  System.Windows.Forms.dll!System.Windows.Forms.Form.ShowDialog(System.Windows.Forms.IWin32Window owner) Line 5898 C#
  System.Windows.Forms.dll!System.Windows.Forms.Form.ShowDialog() Line 5783 C#
  DesignSurface.dll!TestConsole.Program.Main() Line 28 C#

2. Link to Related Issue:

• This issue appears to be connected with Issue 11866. Both issues should be investigated together as they may have a common underlying cause.

3. Naming Resolution Differences:

• The issue is related to the different behaviors in naming resolution between InProc and Runtime.
• InProc: Uses CodeDomDesignerLoader to resolve names, which has context awareness of the designer and can avoid naming conflicts.
• Runtime: Even though it includes a CodeDomDesignerLoader, it actually uses NameCreationServiceImp from the DesignSurfaceExt namespace, which lacks context awareness and cannot detect other controls with the same name.

Services Being Called on Runtime:

No awareness of the designer's context to see if there are components who already possess the same name:

Services Being Called on InProc:

ComDomDesignerLoader has awareness of the designer's context and so it can verify if a control of the same name already exists:

4. Challenges:

• It appears that in the Runtime repo, NameCreationServiceImp is intentionally used instead of CodeDomDesignerLoader. Attempts to force the debugger to step into CodeDomDesignerLoader logic were unsuccessful, even after following the steps outlined in the Debugging CoreCLR.
• A potential workaround might be to manually differentiate the names between toolStripSeparator1, toolStripSeparator2, and toolStripSeparator3 in NameCreationServiceImp.

Next Steps

I'm currently uncertain on how best to resolve this issue. I'm considering two possible approaches:

1. Continue investigating how to correctly utilize CodeDomDesignerLoader in the Runtime context.
2. Implement a manual naming differentiation within NameCreationServiceImp.

@LeafShi1 @Epica3055 @SimonZhao888 @Tanya-Solyanik @lonitra , any thoughts or suggestions would be greatly appreciated.

[Tanya-Solyanik]

@ricardobossan - thank you for the investigation. Name should be created in NameCreationServiceImp or some other component outside the S.W.F.Design namespace because in the InProc designer it was done in the VisualStudio-only component as well. We simulate VisualStudio with the "SurfaceExt" implementations. However INameCreationService.CreateName is not called for the separator control, so I don't see how you can do it outside the .Design namespace.

If you don't see any simple solution either, then the nested DesignerHost is required. However we will not implement it right now, we'll wait for customer requests for DataBinding in the runtime designer support. So if there is not simple solution , we'll won't fix this bug.

[ricardobossan]

Closing this issue, whose underlying cause is already being tracked by #11866 .