`Button.IsDefault` is confusing

[tig]

The other issue, where any other peer view (in this case a StatusBar) of an IsDefault button that raises Accept causing the button to Accept is actually BY DESIGN. This is literally what Button.IsDefault means.

That said, I think the design of IsDefault is confusing.

Originally posted by @tig in #4167

[tig]

Moving @tznind comment here:

If a peer-View receives Accept and does not handle it

This is where the issue lies - most people would consider registering an Accepting handler and doing something in it to be 'handling it'.

Its only after seeing odd behaviour that you explore e and see it has a Handled property. I wonder if we could have static analyzer flag this as warning.

CSX - Accepting event handler is not setting Handled in any branches

[BDisp]

I think it shouldn't be the Button that decides whether it is Default or not, but the Toplevel that decides. There should be the AcceptButton and the CancelButton. It doesn't make sense to have more than one default button for both Accept and Cancel. The Toplevel can have precedence over the keyboard execution in relation to the currently focused view by defining a property. My only doubt is whether it should add these properties in the Application class or in the Toplevel class.

I propose the following:

• Replace the Button's IsDefault property with a method to check whether it is Default or not.
• Add the AcceptButton, CancelButton and KeyPreview or KeyPrecedence properties to the Toplevel as an instance or to the Application as static.