Develop Reference

C# UI Automation API with multiple virtual desktops on Windows 10

Warning, I'm coming into this problem as someone who had never used C# before a couple of days ago...
I'm trying to write a "simple" program that scrapes text from a targeted window and displays it on a 2x20 VFD display. I've learned about using the Microsoft UI Automation API, and have had some success in using it to accomplish my goal.
However, if the target window is on a different virtual desktop it seems that using TreeWalker on the AutomationElement.RootElement will not find the target.
The code I'm using now to get my target window (while it's on the same virtual desktop):
public static AutomationElementCollection FindByMultipleConditions(AutomationElement anElement)
{
if (anElement == null)
{
throw new ArgumentException();
}
Condition conditions = new AndCondition(
new PropertyCondition(AutomationElement.ControlTypeProperty, ControlType.Pane),
new PropertyCondition(AutomationElement.IsContentElementProperty, true),
new PropertyCondition(AutomationElement.IsControlElementProperty, true),
new PropertyCondition(AutomationElement.IsKeyboardFocusableProperty, false),
new PropertyCondition(AutomationElement.IsEnabledProperty, true),
new PropertyCondition(AutomationElement.ClassNameProperty, "Chrome_WidgetWin_0")
);
AutomationElementCollection elementCollection =
anElement.FindAll(TreeScope.Children, conditions);
return elementCollection;
}
An AutomationElement.RootElement is passed to this method, and this seems to be granular enough to always target the specific window I'm interested in, but it returns nothing if my target window is moved to a different virtual desktop.
Is this a limitation of using the UI Automation API to accomplish my task? Is there a way to iterate through each virtual desktop while searching for my target window or should I try a different way of approaching this?
Thanks!

The managed "System.Windows.Automation" library is old and predates multiple desktops being implemented in Windows as far as I know.
You should try to use the new automation api introduced in Windows 8. Sadly it's not managed, but there is great library called FlaUI that makes it as easy to use as the managed library (be sure to use FlaUI.UIA3 not FlaUI.UIA2 when using it to use the new api).
If you don't want a full library then there is a nuget wrapper for the new com api (from the same guys behind FlaUI I think).
Good luck.

TestStack/White API

I'm trying to automate an application using TestStack/White API (Which is based on Microsoft's UI Automation library).
The problem is the following:
At a certain point of automation, I have to deal with an "Dialog" window, which looks to be a separate process, if i look at "Windows Task Manager". But no matter how i try to access the "Dialog Window" (Class, ID, Text, ControlType, etc.) I'm not able to access it.
You can find the UISpy image and code below...
Using UISpy - Dialog Information
using (var DISCLAIMER_App = Application.Attach(#"PathToExecutable"))
using (var DISCLAIMER_Window = DISCLAIMER_App.GetWindow(SearchCriteria.ByClassName("#32770"), InitializeOption.NoCache))
{
var IAccept_button = DISCLAIMER_Window.Get<Button>(SearchCriteria.ByText("I accept"));
IAccept_button.Click();
}
# I've tried also Application.Launch, Application.AttachOrLaunch.
# I also looked to be sure that the Dialog window is a separated process and doesn't belong to any parent window.
Any suggestions?

Found the Solution, had to use "ProcessStartInfo()" and pass the return data to "Application.AttachOrLaunch()":
var psi = new ProcessStartInfo(#"PathToExecutable");
using (var DISCLAIMER_App = Application.AttachOrLaunch(psi))
Source: http://techqa.info/programming/tag/white?after=24806697

Extract Text from a running Program's Window Title without process.MainWindowTitle

I'm trying to extract text from a Creo 2.0 Window Title. The text will be used to create a folder titled the same as the part number that is opened and in the Window Title. The issue I have is that I can iterate through, and find all the Window Titles of open applications using process.MainWindowTitle, but for some reason, Creo doesn't have a Main Window Title. It also doesn't have the text using any other "process." functions. I figure that the information has to be somewhere if it's in the title bar like other normal programs, but I'm just not going at it the right way. Is there another process using C# that I can use to try and accomplish this?
Let me know if I need to give any other information. Thank you for the help!

It may not necessarily be available via the Process object. Explorer.exe, for example, has the current folder name in the title bar but this is not the MainWindowTitle. Another option is to use UI Automation to inspect the UI and report the window's title. Depending on which version of .Net you are targeting, you can reference UiaComWrapper (which has more information and better perf, I believe) or UIAutomationClient and UIAutomationTypes. A short sample that prints all window titles:
using System;
using System.Diagnostics;
using System.Windows.Automation;
static void Main(string[] args)
{
var windows = AutomationElement.RootElement.FindAll(TreeScope.Descendants,
new PropertyCondition(AutomationElement.ControlTypeProperty, ControlType.Window));
foreach(AutomationElement window in windows)
{
var props = window.Current;
var proc = Process.GetProcessById(props.ProcessId);
Console.WriteLine("{0} {1} {2}", props.ProcessId, proc.ProcessName, props.Name);
}
}
Note that you need to run this elevated if you want to get information on elevated processes.

An error occurred executing the click atom

Using C# and Selenium, I am building an automated script where I, amongst other things, try to select a certain value from a droplist (value being specified in a .csv-file). I get the error;
"An error occurred executing the click atom (WARNING: The server did not provide any stacktrace information)"
I have no idea what a click atom is, much less how to fix it... Any help is appreciated greatly!
thanks in advance
this is the code for the droplist:
public bool isellHOSelectAdultsDroplist(string adults)
{
writeToLog(String.Format("Selecting adults from drop list"), this.GetType().Name);
String xpathString = HO_ADULT_SELECTION;
if(GpoExplicitWaitXpathElement(xpathString, 3, 5))
{
IWebElement dropListObjects = webDriver.FindElement(By.XPath(xpathString));
writeToLog(String.Format("DEBUG: Trying to click on appropriate number of adults..."), this.GetType().Name);
selectValueFromAdultDropList(dropListObjects, adults);
return true;
}
else
{
return false;
}
}
//...and this is my select-method
private void selectValueFromAdultDropList(IWebElement dropListObjects, string adults)
{
SelectElement manipulateDroplistObject = new SelectElement(dropListObjects);
manipulateDroplistObject.SelectByValue(adults);
String selection = manipulateDroplistObject.SelectedOption.Text;
int numberOfElements = manipulateDroplistObject.Options.Count;
writeToLog("Number of elements in Adult Droplist: " + numberOfElements, this.GetType().Name);
writeToLog("Selection from adult droplist: " + selection, this.GetType().Name);
}

I'll answer the specific question you asked, which is, "What is a click atom?" There is quite a bit of functionality in the IE driver, and the implementation of this functionality rests on three pillars.
First is IE's COM interfaces. These are the objects and methods that have been used to automate various parts of IE for more than a decade.
The second technology is so-called "native events." That is, using OS-level mechanisms to perform user interactions, like key presses and mouse clicks. On Windows, that means using the Windows SendMessage API. Almost anytime you're using the keyboard or the mouse with the IE driver, you're using native events by default.
Finally, a good portion of the IE driver functionality is implemented using JavaScript functions, which are shared by all of the browsers. These functions are known as "automation atoms".
One of the very few exceptions to using native events for mouse operations is in selecting an <option> element from a <select> element. Since IE doesn't give discoverable dimensions to <option> elements, the IE driver is forced to simulate the click action via JavaScript. This means using the automation atom for the click action. In your case, something must've gone wrong executing that JavaScript, which was faithfully reported as a "failure to execute the click atom." Without more detail, including sample HTML pages to reproduce the issue, it will be exceedingly difficult to diagnose the root cause of the issue.
It's at this point I will echo the call to update to the latest IE driver. Some of the code in this area has been overhauled, and at the least, it should be possible to extract more precise errors from failure cases with a more recent driver.

Use C# to interact with Windows Update

Is there any API for writing a C# program that could interface with Windows update, and use it to selectively install certain updates?
I'm thinking somewhere along the lines of storing a list in a central repository of approved updates. Then the client side applications (which would have to be installed once) would interface with Windows Update to determine what updates are available, then install the ones that are on the approved list. That way the updates are still applied automatically from a client-side perspective, but I can select which updates are being applied.
This is not my role in the company by the way, I was really just wondering if there is an API for windows update and how to use it.

Add a Reference to WUApiLib to your C# project.
using WUApiLib;
protected override void OnLoad(EventArgs e){
base.OnLoad(e);
UpdateSession uSession = new UpdateSession();
IUpdateSearcher uSearcher = uSession.CreateUpdateSearcher();
uSearcher.Online = false;
try {
ISearchResult sResult = uSearcher.Search("IsInstalled=1 And IsHidden=0");
textBox1.Text = "Found " + sResult.Updates.Count + " updates" + Environment.NewLine;
foreach (IUpdate update in sResult.Updates) {
textBox1.AppendText(update.Title + Environment.NewLine);
}
}
catch (Exception ex) {
Console.WriteLine("Something went wrong: " + ex.Message);
}
}
Given you have a form with a TextBox this will give you a list of the currently installed updates. See http://msdn.microsoft.com/en-us/library/aa387102(VS.85).aspx for more documentation.
This will, however, not allow you to find KB hotfixes which are not distributed via Windows Update.

The easiest way to do what you want is using WSUS. It's free and basically lets you setup your own local windows update server where you decide which updates are "approved" for your computers. Neither the WSUS server nor the clients need to be in a domain, though it makes it easier to configure the clients if they are. If you have different sets of machines that need different sets of updates approved, that's also supported.
Not only does this accomplish your stated goal, it saves your overall network bandwidth as well by only downloading the updates once from the WSUS server.

If in your context you're allowed to use Windows Server Update Service (WSUS), it will give you access to the Microsoft.UpdateServices.Administration Namespace.
From there, you should be able to do some nice things :)

P-L right. I tried first the Christoph Grimmer-Die method, and in some case, it was not working. I guess it was due to different version of .net or OS architecture (32 or 64 bits).
Then, to be sure that my program get always the Windows Update waiting list of each of my computer domain, I did the following :
Install a serveur with WSUS (may save some internet bandwith) : http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=5216
Add all your workstations & servers to your WSUS server
Get SimpleImpersonation Lib to run this program with different admin right (optional)
Install only the administration console component on your dev workstation and run the following program :
It will print in the console all Windows updates with UpdateInstallationStates.Downloaded
using System;
using Microsoft.UpdateServices.Administration;
using SimpleImpersonation;
namespace MAJSRS_CalendarChecker
{
class WSUS
{
public WSUS()
{
// I use impersonation to use other logon than mine. Remove the following "using" if not needed
using (Impersonation.LogonUser("mydomain.local", "admin_account_wsus", "Password", LogonType.Batch))
{
ComputerTargetScope scope = new ComputerTargetScope();
IUpdateServer server = AdminProxy.GetUpdateServer("wsus_server.mydomain.local", false, 80);
ComputerTargetCollection targets = server.GetComputerTargets(scope);
// Search
targets = server.SearchComputerTargets("any_server_name_or_ip");
// To get only on server FindTarget method
IComputerTarget target = FindTarget(targets, "any_server_name_or_ip");
Console.WriteLine(target.FullDomainName);
IUpdateSummary summary = target.GetUpdateInstallationSummary();
UpdateScope _updateScope = new UpdateScope();
// See in UpdateInstallationStates all other properties criteria
_updateScope.IncludedInstallationStates = UpdateInstallationStates.Downloaded;
UpdateInstallationInfoCollection updatesInfo = target.GetUpdateInstallationInfoPerUpdate(_updateScope);
int updateCount = updatesInfo.Count;
foreach (IUpdateInstallationInfo updateInfo in updatesInfo)
{
Console.WriteLine(updateInfo.GetUpdate().Title);
}
}
}
public IComputerTarget FindTarget(ComputerTargetCollection coll, string computername)
{
foreach (IComputerTarget target in coll)
{
if (target.FullDomainName.Contains(computername.ToLower()))
return target;
}
return null;
}
}
}