MenuItem Invoke() is blocking

[jakubsuchybio]

In MSFT Docs: https://docs.microsoft.com/en-us/windows/desktop/api/UIAutomationClient/nf-uiautomationclient-iuiautomationinvokepattern-invoke
there is

Remarks
Calls to this method should return immediately without blocking. However, this behavior depends on the implementation.

So on Windows 10 with Win.Forms app it is blocking.

The problem with this is, that this MenuItem which I am Invoking creates modal window and I need to perform some action on that modal window with FlaUI, but I can't, because that Invoke won't return until the modal window is closed.

I tried to go around by making invoke as non-awaited task, which in theory would result in that Task getting blocked by Invoke, but the rest of the code would find that modal window, close it and in that instant the blocked Task would end.

However this doesn't work and I don't know why :(

I tried to reproduce it with notepad.exe, but I couldn't. It works in notepad. I then looked at FlaUIInspect if there is a difference between notepad's Help->About and our software Help->About and it is...
See here: https://i.imgur.com/PoqoHLr.png
For some reason FlaUIInspect can't find our HelpDropDown Items.

Here are selected menus from both apps:
https://i.imgur.com/2zr7uNN.png
https://i.imgur.com/mr5oOxO.png

I looked into our code for something that could be breaking this, but I found only standard things. The only difference that could do this is that our HelpMenu is not statically set from designer at startup, but it is dynamically created at runtime after some logic is checked.

Any ideas about this? :/

[Roemer]

I've had this problem as well. Microsoft says to us a multi-threaded approach for this issue (as you did). But I myself had issues with multi-threading UI tests as well. I mostly stayed with single-threaded and avoided blocking in such cases with using the mouse and Click.
About the menu: Did you check if there is an element directly on the desktop with the same process id as your application? Sometimes the menu items / context menu items are direcly below the desktop element (In an empty window).

[jakubsuchybio]

I will check finding it on the root app and not inside menu. However I don't think it will be found, because of what is shown in those images in my previous post

@Roemer Yeah, so the bounding rectangle is "Not Supported" in inspector for that sub menu item.

[AyoubLHY]

Have you tried to get the bounding rectangle even though is not supported?
in my case , bounding rectangle is not supported but this lines works for me, and solved the same issue you have:
Rectangle r = menuItem.AsButton().BoundingRectangle; Mouse.LeftClick(new Point(r.X, r.Y));

[Ben-Mack]

Whenever menuItem.Invoke() run in another thread, then all kind of window.FindFirstDescendant afterward just won't work, always return null.
@Roemer Do you know any solution/workaround for this?

Sample code:

ThreadPool.QueueUserWorkItem(state => {
  openFile.AsMenuItem().Invoke();
});

var openWindow = window.FindFirstDescendant(cf => cf.ByControlType(FlaUI.Core.Definitions.ControlType.Window));

I can't use menuItem.Click(false) because if user happen to moving the mouse then Click will miss its target, sometime it click on the nearby button, so Invoke is the only reliable option for my automation ultility.
Or do you know how to make Click more reliable? I intended to BlockInput before click but BlockInput require Admin rights, so not possible in my case. Also tried the above solution but still same.

[dubpal]

I would also be interested in a workaround (I've switched all my .Click() calls to Invoke(), in order to let the tests run w/o active rdp/vnc connection).