Using UI Automation, a Winforms Button Invoking Several Times

I am trying to use the MS UI Automation Framework in my application for some automated testing. My goal at this time is to listen for GUI events and record them, similar to the provided sample (TestScriptGeneratorSample) in the Windows SDK.

Just using this demo application, I can start a simple Windows Forms application with a single button and see that it logs click events as a β€œtrigger” UIA event. However, for each press of a button, the demo application logs events 4 . Why is this? I do not see this problem when using the WPF button.

I assume that since the System.Windows.Forms.Button class supports MSAA instead of MCA, the part of the MCA that connects the MSAA interface is to behave badly or at least to behave in a way that I do not understand and cannot find the documentation. Maybe it reports an invoke event for the mouse to click down, up, click, and then press the actual button?

Can someone explain this behavior and / or provide a workaround so that a single click of a button leads to a single call event?

Edit: This is under WinXP SP3. I just installed the Windows Automation API 3.0 update and still see the same behavior.

Edit 2: I found this example where the author offline mentions this behavior as an error in Win32, but does not provide any evidence ...

Here is my sample application (a form with a button on it), as well as listening to events. Add links to UIAutomationClient and UIAutomationTypes . Press the button and see how invoke are executed four times instead of one.

 using System; using System.Drawing; using System.Windows.Automation; using System.Windows.Forms; namespace WindowsFormsApplication6 { public partial class Form1 : Form { private TextBox m_Output; public Form1() { InitializeComponent(); // set up the GUI with a single button... Button b = new Button {Location = new Point(5, 5), Name = "Test", Text = "Click Me"}; // ... and a textbox to write events to. m_Output = new TextBox { Location = new Point(5, 30), Name = "Output", Multiline = true, Size = new Size(250, 200) }; this.Controls.Add(b); this.Controls.Add(m_Output); // get the button as an UIA element AutomationElement button = AutomationElement.FromHandle(b.Handle); // attach a handler to the button, listening for the Invoke event Automation.AddAutomationEventHandler( InvokePattern.InvokedEvent, button, TreeScope.Element, OnInvoked); } // Handler for button invoke events private void OnInvoked(object Sender, AutomationEventArgs E) { AppendText("Invoked: " + ((AutomationElement)Sender).Current.AutomationId); } // Just dumps text to the textbox private void AppendText(string Text) { if (m_Output.InvokeRequired) { m_Output.BeginInvoke((Action<string>)AppendText, Text); } else { m_Output.AppendText(DateTime.Now.ToString("hh:mm:ss.fff") + ": " + Text + Environment.NewLine); } } } } 
+4
source share
1 answer

For what it's worth, I worked on it, filtering several events released into one. During testing, I found the following:

  • The .NET buttons (i.e., Winforms) generate the following events in the following order:
    • Called
    • Called
    • Called
    • Property changed ( Name property)
    • Called
  • The Win32 buttons generate the following events in some scenarios ( calc.exe buttons):
    • Changed property ( HasKeyboardFocus property)
    • Called
  • The Win32 buttons generate the following events in other scenarios ("Cancel" in the file save dialog box):
    • Called
    • Changed property ( HasKeyboardFocus property)
    • Called

Using the FrameworkId property in AutomationElement , which is associated with the event, I can distinguish between the first and second two situations (this is "Winform" for the .NET buttons and "Win32" for the Win32 buttons). Then, for the two Win32 scripts, I just guarantee that I received the HasKeyboardFocus property change event before recording the called event.

I have not yet seen that this does not work, since I always get a HasKeyboardFocus property change event, even if the button has already been focused (i.e. I click it twice).

I would still like to see a deeper understanding if anyone has ...

0
source

Source: https://habr.com/ru/post/1436241/


All Articles