Develop Reference

Programmatically select DrawingObject in HWindowControlWPF

I'd like to select a created DrawingObject to highlight it and show the handles without the user needing to click it. I am using Halcon 13 and tried using SendMouseDoubleClickEvent() (Docu) but this only seems to be available for the new Halcon Smart Window, which is currently not an option for me as it interacts differently with the Halcon-Procedures. I also tried to use SelectObj() (Docu) but this seems to do something entirely different.
I have:
a reference to the HWindowControlWPF
the ID of the HWindowControlWPF
the ID of the DrawingObject
Any help or hint is appreciated!

I could not find a proper solution to this problem but I found a hack that achieves the same result:
First, detach all drawing objects apart from the one you want to show as selected via DetachDrawingObjectFromWindow. Then, reattach them via AtachDrawingObjectFromWindow.
This works because the Halcon Window automatically selects the last attached drawing object.

Off screen element teststack white

I need to automate 3rd party WPF application. I use
TestStack/White. This application has menu bar that is presented by images. After some actions menu is changing. There presents new images. When I want to click on new image:
Window mainWindow = application.GetWindow("Main window", InitializeOption.NoCache);
Image newTask = mainWindow.Get<Image>(SearchCriteria.ByControlType(ControlType.Image).AndIndex(2));
newTask.Click();
I get exception:
TestStack.White.AutomationException: Cannot perform action on Image.
AutomationId:, Name:, ControlType:image, FrameworkId:WPF, element is
offscreen.
I use Microsoft Inspect for research elements.
When I start tests, Inspect show me that image is offscreen. But if I do these actions manually, it works perfectly and in Inspect this image is not offscreen.
How can I refresh these elements or clear cache of window?

There are ReInitialize and ReloadIfCached methods on Window object. Try those to see if something changes.
Are you sure AndIndex(2) is correct element in that particular situation?
Try using GetMultiple and iterate the collection to see what images you actually have and which are not Offscreen.
WPF automation with White is pretty hard. Try Telerik Testing Framework and White could be supporting framework. It is much more easier that way.

It can be a problem with focus, try to use this before getting image:
mainWindow.Focus(DisplayState.Maximized);

Not an exact answer but the final solution I've got after all these TestStack.White not found elements, table rows, and so on. I started to move it to FlaUI. If something does not work or unstable with White then most likely I can get more stable and fast-executable FlaUI solution.
Fortunatly, such migration can be done with little steps. For example I already have TestStack.White.Application app, then I replace White portion of code with FlaUI like this:
var flApp = FlaUI.Core.Application.Attach(app.Process.Id);
using (var automation = new UIA3Automation())
{
// .. new UI element processing
}

I don’t think that caching is the problem here. You are getting the mainWindow with InitializeOption.NoCache. In Non-cache mode the controls are found on demand. So I presume that the cache is refreshed automatically. (https://github.com/TestStack/White/blob/master/src/TestStack.White/Factory/InitializeOption.cs)
Perhaps the index of the element you want to click is not 2.
Have you tried adding an explicit wait? It sounds like you have only tried adding an implicit wait.(https://github.com/TestStack/TestStack.docs/blob/master/_source/White/Advanced%20Topics/Waiting.md)

Why does FindFirst in UIAutomation takes so long?

I'm trying to automate a part of our application WinForms/MFC application (to be able to perform automated tests) - however, currently I'm struggling with slow finding of the main menu (SysTreeView32 control) - basically the central component, which enables access to all the screens which I need to test.
I tried to find it with AutomationElement.FindFirst(), also with the TreeWalker.GetFirstChild(), but both methods seem far too slow.
What was interesting, once I started interaction with this TreeView during the time the test was trying to find the control - like expand/collapse some items, move with the mouse over the tested application - the control was found almost immediately.
What's the catch? Application is reacting very smoothly - only lookup process takes ages, when the app is inactive.

I had the same problem trying to find a child of my main window. You should give as many details as you can (filter things out) so that the search goes faster. In my case, I had a Save As Window, I added the following:
The window should be a ControlType.Window
AndCondition
The AutomationElement.NameProperty of the window should be: "Save As"
var saveWindow = appElement.FindFirst(TreeScope.Children | TreeScope.Descendants, new AndCondition(new PropertyCondition(AutomationElement.ControlTypeProperty, ControlType.Window), new PropertyCondition(AutomationElement.NameProperty, "Save As")));
You need to do further tests to determine if the AutomationElement you are searching for can be found within the Descendants or the Children and skip search in one of them if necessary. In my case, the code above worked fine, but in a subsequent step, I required to find the Edit control / Text box next to "File name:" so I first created a condition:
var saveWindow = appElement.FindFirst(TreeScope.Children | TreeScope.Descendants, new AndCondition(new PropertyCondition(AutomationElement.ControlTypeProperty, ControlType.Window), new PropertyCondition(AutomationElement.NameProperty, "Save As")));
And then added the condition to the search:
var fileName = saveWindow.FindFirst(TreeScope.Children | TreeScope.Descendants, fileNameCondition);
Strangely, and probably because of UIAutomation limitations, and unexpected behaviour, the line above was finding the element instantly in a Windows 10 Creators Update machine, but was getting stuck in a Windows 10 Anniversary Update... so after some debugging I found out that I could find the element by just searching in the children and that found it instantly in. both machines:
var fileName = saveWindow.FindFirst(TreeScope.Children, fileNameCondition);

how do I make my application as fast as windows explorer for rendering files

I have a folder with a large amount of files inside of it. I want to be able to render each of my files as a button. And when I click on the button something will happen.
private void Form1_Load(object sender, EventArgs e)
{
int x = 10;
int y = 10;
/// Process the list of files found in the directory.
string[] fileEntries = Directory.GetFiles(#"c:\lotsofDocs");
foreach (string fileName in fileEntries)
{
// do something with fileName
Button newbotton = new Button();
newbotton.AutoSize = true;
newbotton.Text = fileName;
panel1.Controls.Add(newbotton);
newbotton.Location = new Point(x, y);
x += 150;
if (x == 760)
{
y += 50;
x = 10;
}
}
As you can see there's nothing crazy in the code. I have a panel on a form and I've set auto scroll on the panel to true and auto size to false. This causes the form to maintain size and the buttons (some of them anyway) to get rendered off the form and I can scroll down to them.
All good so far.
If I have 100 or 200 file everything is ok, if I have 1932 files it takes about 10 seconds to render all the buttons.
I've read the follow question Super slow C# custom control and I understand that the approach I'm using might not be the best to use here.
And now the question at last:
how does windows explorer handle this? If I open this folder in Windows explorer it opens instantly.
What type of control is windows explorer using? Or is it doing it in a completly different way to me.
Thanks

Very long lists of controls are usually implemented via virtualised controls. That means that if only 20 buttons fit on the screen it only creates 20 buttons or so. When you scroll around it reuses the same 20 buttons with new data in them.
Controls can be very slow to create and manage in large numbers as they are usually added to a simple list or hierarchy (and are quite complex individually).
Better off managing a smaller set of buttons yourself to show a very long list of data. More work obviously, but the end result is lightning fast compared to the "simple way".
If you don't want to DIY, try a third party control. As an example the Telerik virtualised Tree, List and Grid controls can display a million records with no slowdown. Take a look at their Winforms grid here

You should look at the ListView. It provides the same basic set of functionality as the file area in Windows Explorer with comparable performance.
Make sure to call BeginUpdate before adding your items and EndUpdate when you are done for the best performance. Adding your items with Items.AddRange is also good for performance.

Can you allocate all the buttons at once? What I mean is, create an array of buttons after you read the file names (so you know how many buttons to create), then simply set their properties in the loop. I don't know how much that will speed things up, but it's worth a try. You might also see if there's an override on the panel's Add method that takes an array or list of controls and add them all at once, too.

One trick that often helps improving slow contruction / change operations is to hide the controls and / or the parent container involved. In your case, that would mean hiding panel1 before creating the controls, and showing it again afterwards. Might not help a bit in your case, but it's worth a try.
However, you will have fundamental problems creating so many controls in Win32 or WinForms. While the Window System now can handle these, it's not the thing tries to be good at.
It is also not the best user interface for that. 2000 Buttons in a 5 x 400 matrix? Holy effin' cow. I don't want to use that. What do you do if a file name does not fit 150 pixels? What do you do on displays where "150" means ".15 mm"?
Alternatives
Why not a list control? That at least has page up / page down, and type ahead to find items starting with the text I enter. Throw in a "quick filter" edit control on top of it, where where entering some text filters out any files that don't contain it, and you have a standard interface that can be used efficiently. If you expect many items, you can put the LitView control into virtual mode. While this loses some built-in features (e.g. autosizing columns), it works with insane numbers of items thrown at it.
You could also render the buttons as HTML links, and show it inside a browser control. That's not necessarily faster, but HTML renders progressively, I can use the list while you are still feeding items.

AccExplorer doesn't find new controls / thinks old controls are still around

Our application has many controls that are created dynamically. For example, a navigation pane contains groups of links that change as the user navigates through the app. The first time I use AccExplorer to select these links, it finds them perfectly. However, after I navigate to another page, AccExplorer can't see the links in the updated navigation pane. In fact, the old link controls still appear in the AccExplorer tree hierarchy and as I click on them AccExplorer highlights areas of the desktop that are outside the bounds of our application's actual window.
The controls have changed, but AccExplorer doesn't recognize them. It still thinks the hierarchy is the same.
What I find strange is that closing AccExplorer and then opening a new instance of AccExplorer results in the same results. When I select the new navigation control with AccExplorer, it doesn't see the new links. It recreates the old hierarchy with the old links. The only way to see the new links is if I close our application, reopen our application, manually navigate to the new page, then select the controls with AccExplorer.
The navigation control is a DevExpress control. OS is WinXP. AccExplorer 2.0. I'd prefer to use UIAutomation, but not all DevExpress controls support UIAutomation. We're trying to use MSAA to fill in those gaps.

To follow up...
With UISpy I'm able to find a control called LeftNavExplorerBarGroups that AccExplorer cannot see. I'm able to use UIAutomation to get the window handle of the control then use the handle to find the IAccessible object with MSAALayer. The fact that AccExplorer can't see that control and that the accName is null made it very difficult to discover how to find the controls I needed. (Note: MSAA comes from Arshad - http://www.codeproject.com/KB/winsdk/MSAA_UI_Automation.aspx)
AutomationElement a, b;
Process p;
Process[] existingProcesses;
IAccessible c;
existingProcesses = Process.GetProcessesByName("OurApp");
if (existingProcesses.Length > 0) {
p = existingProcesses[0];
a = AutomationElement.FromHandle(p.MainWindowHandle);
b = a.FindFirst(TreeScope.Descendants, new PropertyCondition(AutomationElement.AutomationIdProperty, "LeftNavExplorerBarGroups"));
c = MSAA.GetAccessibleObjectFromHandle(new IntPtr(b.Current.NativeWindowHandle));
}