Form.ActiveForm does not return null when an owned model window should not be "active"

• .NET Core Version:

.NET Core 3.1

• Have you experienced this same bug with .NET Framework?:

Yes

Problem description:

When a form is showed the ActiveForm property on a form returns the form (if main form returns that), or null when a window from another process is active. However when on a Model form with the main form as the owner, doing that results in the property always returning that Model form instead of null like I think it should. Not even the Deactivate nor the Activated events fire when this happens.

Expected behavior: for ActiveForm to return null when no forms (including model forms with the main form as owner) when a window from another application is active. Same for the Activated/Deactivate events should also fire as well when this happens or when reclicked on that should make it become Activated again.

Minimal repro:

1. Create a new winforms project.
2. Create a in the Form1 code make the form create another form a button in it is clicked making that form the owner of another instance of itself.
3. Do some painting work that uses the Paint event on the form code that changes colors when

// this.active is an added attempt to double check and make sure it is
// active using the Activated/Deactivate events.
if (Equals(ActiveForm, this) && this.active)
{
    // e.Graphics stuff.
}
else
{
    // e.Graphics stuff.
}

[weltkante]

As far as I understand the documentation, Windows does not send an SC_CLOSE - the menu item is the SC_CLOSE. Getting a WM_SYSCOMMAND is just Windows telling you someone clicked a menu item in the system menu, SC_CLOSE is just the ID of the menu item. The default handling of clicking the menu item will be to close the window. (In other words, WM_SYSCOMMAND+SC_CLOSE is not the reaction to clicking a menu item, it is the event of clicking the system menu item ‘SC_CLOSE’. The reaction to clicking that menu item is sending a WM_CLOSE to close the window. You might be mixing up cause and reaction.)

So if you create a custom menu then obviously it no longer is identical to the SC_CLOSE menu item and there won’t be any default behavior. Instead of sending an SC_CLOSE windows will call the event that your menu item was clicked.

If you meant to say you were manually sending WM_SYSCOMMAND+SC_CLOSE from a ContextMenuStrip and it didn’t work, then it likely is the same reason it didn’t work for the form click, someone probably has mouse capture on. The WinForms API only allows you to reset mouse capture if you access it through the property of the control which currently holds capture. If the capture is not held by WinForms or you can’t access the control which holds it you could try using native API to force release of the capture.

[RussKie]

Closing as I don’t believe there is anything outstanding from our side. @AraHaan holler back, if it is not the case.

@weltkante thank you for your help!