Why does TopLevel.Activate/Deactivate exist? Why is this just not Focus?

[tig]

@BDisp - I believe you have the most knowledge of this area.

In thinking through View in v2, I've come across this and I don't understand why the concept of "Actviate/Deactivate" is needed. Why couldn't we have just used Focus? Is there a difference between a Toplevel being "active" and "having focus"?

[BDisp]

The Activate/Deactivate only works if IsMdiContainer is true at Application level. If you want to remove the Mdi concept you can replace it by calling the OnEnter/OnLeave which will invoke the Enter/Leave events. See the BackgroundWorkerCollection.cs scenario that the only that uses the Mdi concept, by running some works and waiting by the resulting workings and navigate through all the windows and see the WorkApp logger. See also the Window menu where all the opens windows appear with the current selected. They are MdiChildes. For unit tests search for IsMdiContainer and the ApplicationTests.cs, MdiTests.cs and ToplevelTests.cs.

[tig]

I don't think I was clear in my question. Let me try again...

How is "activate/deactivate" different than "enter/leave"?

Is the "activate/deactivate" concept really needed in addition to "enter/leave"?

I'm asking this in context of v2 where we can choose to rewrite unit tests if we choose to make breaking api changes.

[BDisp]

How is "activate/deactivate" different than "enter/leave"?

Yes because Activate/Deactivate are used on toplevels that are running different RunState. Enter/Leave are used on the same toplevel that is running the same RunState which handle the focus between the subviews. I think I try to use the Enter/Leave first but I had strange behaviors. So, I decided to use the same event as WinForms.

Is the "activate/deactivate" concept really needed in addition to "enter/leave"?

For dealing with interchanges with different RunState I think we need it, like take some needed actions.

I'm asking this in context of v2 where we can choose to rewrite unit tests if we choose to make breaking api changes.

I really haven't idea on the effect if this is changed. You have to test in your changes to see if Enter/Leave work as expected.

[tznind]

Could we have an Enter/Leave event args that captured the required information? For example EnterEventArgs could have a field representing if it is a top level focus change from another window?

I don't know exactly what the variables are but I would like to see us standardise on the sender EventArgs pattern for all events so we can put relevant info in and expand over time if needed without it being a breaking change.

[BDisp]

@BDisp - Very helpful. Thanks.

I don't know exactly what the variables are but I would like to see us standardise on the sender EventArgs pattern for all events so we can put relevant info in and expand over time if needed without it being a breaking change.

[tig]

I don't know exactly what the variables are but I would like to see us standardise on the sender EventArgs pattern for all events so we can put relevant info in and expand over time if needed without it being a breaking change.

I concur: #2359