When the CanFocus property is set to false, the Accepting event is executed 3 times

[luizfernandonb]

To Reproduce
Steps to reproduce the behavior:

1. Copy the code below

var window = new Window();
window.Title = "test1";

var btn = new Button();
btn.Title = "test2";
btn.X = Pos.Center();
btn.Y = Pos.Center();
btn.CanFocus = false;
btn.Accepting += (_, _) => {
    Debug.WriteLine("accept");
};

window.Add(btn);

Application.Init();
Application.Run(window);
Application.Shutdown();

2. Run in your IDE or text editor

Expected behavior
The event will only be executed once

Screenshots
When executing the code above I have this in the Visual Studio output:

If I comment out the CanFocus property code, I have this in the Visual Studio output:

Desktop (please complete the following information):

• OS: Windows 11 24H2 26100.2894
• Browser: Microsoft Edge
• Version: 132.0.2957.140

Additional context
It's in v2

[tig]

I'll look at this asap. thanks!

[tig]

There is confusion here (and a bug):

First, the name of the event is Accepting, not Accept. This is intentional. It indicates the event is being raised because the user is IN THE PROCESS of accepting something. It is a cancelable event, meaning if it is not cancelled, other things will process it.

If you do not indicate that you handled the Accepting event (by setting e.Cancel = true), here's what happens:

• If there's a peer view that's Button with IsDefault == true Command.Accept will be invoked (not your case).
• If there's a SuperView, Command.Accept will be invoked on it (your case).

You can fix this in your code like this:

btn.Accepting += (_, e) => {
    // If you do something with Accepting, you should indicate you've handled it
    e.Cancel = true;
    Debug.WriteLine("accept");
};

That said, the correct behavior for your test app shouldn't be THREE invocations of your handler. It should be one.

I am working on a fix.

[tig]

FWIW, if you change your code to

var window = new Window();
window.Title = "test1";

var btn = new Button();
btn.Title = "_test2";
btn.X = Pos.Center();
btn.Y = Pos.Center();
btn.CanFocus = false;
btn.Accepting += (_, _) => {
    Debug.WriteLine("accept");
};

window.Add(btn);

Application.Init();
Application.Run(window);
Application.Shutdown();

And the user presses Alt-T we get only a single "accept".

IOW, the bug is in mouse handling. Which is I why I had to do this to reproduce it in a unit test:

        Application.RaiseMouseEvent (
                                     new MouseEventArgs ()
                                     {
                                         ScreenPosition = btnFrame.Location,
                                         Flags = MouseFlags.Button1Pressed
                                     });

        Application.RaiseMouseEvent (
                                     new MouseEventArgs ()
                                     {
                                         ScreenPosition = btnFrame.Location,
                                         Flags = MouseFlags.Button1Released
                                     });

        Application.RaiseMouseEvent (
                                     new MouseEventArgs ()
                                     {
                                         ScreenPosition = btnFrame.Location,
                                         Flags = MouseFlags.Button1Clicked
                                     });

Instead of just doing a Button1Clicked event... Because this is what drivers actually send on a mouse click:

• Press
• Release
• Click

Still working on it...

[tig]

Another clue:

button.CanFocus = false;
button.HighlightStyle = HighlightStyle.None;

Disabling the highlight style on the button hides the issue.

We have a set of fairly convoluted logic in View.Mouse.cs around handling mouse-grab situations. E.g.

  // Post-Conditions
  if (HighlightStyle != HighlightStyle.None || WantContinuousButtonPressed)
  {
      if (WhenGrabbedHandlePressed (mouseEvent))
      {
          return mouseEvent.Handled;
      }

      if (WhenGrabbedHandleReleased (mouseEvent))
      {
          return mouseEvent.Handled;
      }

      if (WhenGrabbedHandleClicked (mouseEvent))
      {
          return mouseEvent.Handled;
      }
  }

[tig]

Ok, the bug is DEEP and I have decided not worth fixing.

The logic for dealing with mouse events is simply too fragile and convoluted.

@tznind and I are working on addressing this as part of

• Fixes #3692++ - Rearchitects drivers #3837

Related

• HighlightOnPress and/or WantContinousButtonPressed has issues with nested subviews. #3753
• Mouse doubleclick stops continous pressed events. #3404
• Mouse API makes it way too hard to track button pressed #3312
• WindowsDriver makes it impossible for an app to get fast mouse clicks #3385

I'm closing this as "By Design; Won't Fix".

@luizfernandonb - You have several ways of dealing with this:

1. Set e.Cancel = true in your Accepting handler. This is the correct fix for your code as posted.
2. Turn off highlighting on your button (btn.HighlightStyle = HighlightStyle.None)

I have added more unit tests as part of #3921.

[luizfernandonb]

Thanks!