2013-05-19

My Libraries are your libraries.

I say that because on this website you will find many C# & WPF libraries for the daily development.

The libraries have several benefits: - well and complete documentation, - detailed description pages, - intellisense and debugging symbols, - open source, - for free for any kind of application. Each library is licensed under the MIT License.

If you for example develop with the MVVM pattern or search for controls which are not inside the .Net framework, you should have a look into the libraries on this page. In most cases you will find an appropriate and reasonable solution. If you just need one control instead of a whole library, you have the freedome to take the sources and copy them into your project.

If you have any question, any problem, need an idea how to solve a problem, have any problem using a library, found an issue or just miss anything, don't hesitate and contact me, I will try to help you.

In the last implementation of the WindowSearcher I was to lazy about testing it, I got reported that child windows were never be found. And main window too if no timeout was set explicit.

I have fixed both in the current version.

  • The Default timeout of the WindowFinder.Search is changed from 0 to 10 seconds like in the ApplicationFactory
  • The WindowSearcher internally is working different than before, now it doesn't matter if the window is a top or a child window, it gets found in few nano seconds

(The usage has not been changed)

 

Facts:

Library: DW.CodedUI
Tool: AutomationElementFinder
Version: 13.5.14.0
Date: 2013-5-14 17:55

 

Today I have cared about the focusability of the TitledItemsControlNumericUpDownControlsTextBox and ButtonBar. (Tabulator key inside the controls)

The NavigationBar, PagingControl, SidePane, SplitButton and TreeComboBox has some keyboard control problems actually, I focus on them later.

 

Facts:

Library: DW.WPFToolkit
Version: 13.5.11.0
Date: 2013-05-11 14:00

 

I was not really happy how the window handling was working in the DW.CodedUI. It was slow (if the window was not available for example) and unsafe.
Because of that I have renewed the handling, the old functionality is marked as obsolete and will be removed in the upcoming versions.
What is changed in detail:

  • Already marked obsolete objects are removed
  • Obsolete overload in the ColorDetector is removed
  • A window is represented by a BasicWindow with some basic functionality like Minimize, Maximize, WindowState and so on
  • WindowFocus now has obsolete methods for the TestableApplication and TestableWindow and gets a new method for the BasicWindow
  • Added WindowFinder to search for windows on a very generic and fast way
  • TestableApplication and TestableWindow is marked as obsolete
  • Shutdown object has overload to close a BasicWindow, the other methods with the WpfWindow and TestableApplication are marked as obsolete
  • ApplicationFactory has a new method to launch an application on a easier way and returns a BasicWindow, the old is marked as obsolete
  • In the AutomationElementFinder the sibling elements are separated by a horizontal line in the left tree

To launch an application now just do like this:

 

[CodedUITest]
public class AnyWindowTests
{
    private BasicWindow _target;
    [TestInitialize]
    public void Setup()
    {
        _target = ApplicationFactory.Launch(@"..\..\..\Anypath\MyApplication.exe");
    }
    [TestCleanup]
    public void Teardown()
    {
        _target.Unsafe.Close();
    }
    [TestMethod]
    public void Method_TestCondition_ExpectedResult()
    {
        var anyButton = BasicElementFinder.FindChildByAutomationId<BasicButton>(_target, "AnyButton");
        MouseEx.Click(anyButton);
        //Assert
    }
}

To search for an already open window call stuff like this:

[TestMethod]
public void Method_TestCondition_ExpectedResult()
{
    var window = WindowFinder.Search("title", WindowSearchCondition.TitleContains, StringComparison.OrdinalIgnoreCase);
    Assert.IsNotNull(window);
    WindowFocus.BringOnTop(window);
    // Do any other stuff with the window
    window.Unsafe.Close();
}

 

See the documentation for details.

 

Facts:

Library: DW.CodedUI
Tool: AutomationElementFinder
Version: 13.5.7.0
Date: 2013-5-7 22:32

 

Just a small update.

With the ApplicationFactory it is possible to launch the application for automated UI testing. This works good but there was one problem, the working directory was not set. If the application does not handle this it was possible that anything has failed because of missing files and so on.
To prevent such problems the ApplicationFactory sets the working directory to the directory the executable to launch is located.

 

Facts:

Library: DW.CodedUI
Tool: AutomationElementFinder
Version: 13.4.5.0
Date: 2013-4-5 17:55

 

Until now the ApplicationFactory and the TestableWindow was able to find a WPF Window by the title only if the whole title has been matched.

But now it is possible to say if the title has to contain the given one or matches exactly.

For details see the Launch parameters in the ApplicationFactory or the constructor overloads in the TestableWindow.

 

 

Facts:

Library: DW.CodedUI
Tool: AutomationElementFinder
Version: 13.2.25.0
Date: 2013-2-25 18:46