Fix issue 15067: Control.Visible binding does not activate when Visible was explicitly set to false before DataBindings.Add was called

[SimonZhao888]

Fixes #15067

Root Cause

Control.Visible binding activation was gated by component creation (ComponentCreated / handle-created path).
When Visible was explicitly set to false before DataBindings.Add, the control could remain in a pre-created state where the binding did not fully activate, so later INotifyPropertyChanged updates were not applied as expected.
Additionally, once enabling early activation for Visible, an immediate initial push from data source could overwrite an explicitly set local Visible value. That required preserving the user/designer-set value on first bind.

Proposed changes

• Treat Control.Visible as a special-case binding that can activate before component creation.
• Update binding activation checks in:
  • Binding.BindToObject.CheckBinding
  • Binding.SetBindableComponent
  • Binding.UpdateIsBinding so Visible bindings are not blocked by handle-creation timing.
• Add logic to preserve an explicitly assigned local Visible value by delaying the initial data push when first transitioning into binding state.
• Add a regression unit test (Add_VisibleBindingOnInitiallyHiddenControl_UpdatesFromDataSource) proving that a control initially set Visible = false still responds to subsequent data-source toggles.

Customer Impact

• Fixes an end-user-visible data-binding bug where controls (e.g., Panel) initialized with Visible = false did not reliably respond to later bound visibility changes.
• Restores expected MVVM/data-binding behavior consistency between controls with default visibility and controls explicitly hidden before binding.
• Low risk and narrowly scoped: behavior change is limited to Visible binding activation/preservation path, with regression coverage added.

Regression?

• No

Risk

• Mini

Screenshots

Before

Recording.2026-09-15.115046.mp4

After

Recording.2026-09-15.115721.mp4

Test methodology

• Manually

Test environment(s)

• 11.0.100-rc.1.26420.103

Microsoft Reviewers: Open in CodeFlow

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 37.24166%. Comparing base (60135a0) to head (d9036b0).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@              Coverage Diff              @@
##                main      #15096   +/-   ##
=============================================
  Coverage   37.24166%   37.24166%           
=============================================
  Files            246         246           
  Lines           9774        9774           
  Branches        1029        1029           
=============================================
  Hits            3640        3640           
  Misses          5970        5970           
  Partials         164         164           

Flag	Coverage Δ
Debug	37.24166% <ø> (ø)
production	39.36526% <ø> (ø)
test	20.64923% <ø> (ø)
unit	39.36526% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Copilot]

🟡 Changes recommended

One or more issues must be addressed before approval.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

Fixes pre-handle Control.Visible binding activation while preserving initially hidden controls.

Changes:

• Enables early Visible binding checks and activation.
• Delays the initial data push for explicitly hidden controls.
• Adds a regression test for source-driven visibility updates.

File summaries

File	Description
src/test/unit/System.Windows.Forms/System/Windows/Forms/ControlBindingsCollectionTests.cs	Updated as part of this pull request.
src/System.Windows.Forms/System/Windows/Forms/DataBinding/Binding.cs	Updated as part of this pull request.
src/System.Windows.Forms/System/Windows/Forms/DataBinding/Binding.BindToObject.cs	Updated as part of this pull request.

Review details

Suppressed comments (2)

src/System.Windows.Forms/System/Windows/Forms/DataBinding/Binding.cs:235

• This new path can create a manager for a pre-created control at design time, even though BindToObject.CheckBinding deliberately returns early when ControlAtDesignTime() is true. That leaves FieldInfo unset; UpdateIsBinding can then activate the binding and PushData() may try to format the entire data source as Visible (or wire runtime notifications) in the designer. Keep the pre-creation exception disabled for design-time components, or otherwise defer activation until the design-time binding check can initialize the field.

                BindableComponent is not null && (IsComponentCreated(BindableComponent) || SupportsBindingBeforeComponentCreated(BindableComponent))
                    ? BindableComponent.BindingContext
                    : null,

src/System.Windows.Forms/System/Windows/Forms/DataBinding/Binding.cs:1171

• When ControlUpdateMode is Never, the existing activation path deliberately calls PullData(..., force: true) because this mode is write-only with respect to the data source. Putting that call behind !shouldDelayInitialDataPush means a hidden control's initial value is neither written to the source nor updated later (PushData() returns immediately for Never), so this changes the documented behavior for this mode. Keep the preservation guard around only the data-source-to-control PushData() branch and still execute the PullData branch.

            if (IsBinding && !shouldDelayInitialDataPush)
            {
                if (_controlUpdateMode == ControlUpdateMode.Never)
                {
                    PullData(reformat: false, force: true);
                }
                else
                {
                    PushData();
                }

• Files reviewed: 3/3 changed files
• Comments generated: 2
• Review effort level: Lite

---

💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.