Wednesday, June 23, 2010

Testing WQL based WMI queries (wbemtest)

Windows Management Instrumentation (WMI) makes life easier for developers to get those information which have been very difficult to get earlier. Not only we can get these information, we can also make them available to any System Management tools like Microsoft System Center. They can be used to provide centralized management and administration of all applications. The administrators are no more required to look at various logs created everywhere on various standalone and network machines.

The real issue is to test our WMI queries. Windows provides a tool to provide just for this. This tool is called WBEMTEST. You can start this by typing WBEMTEST on run box in start menu.



As soon as you press OK, following form is shown on the screen:



Since WMI objects are defined in various namespaces, you would need to connect to the required namespace before querying any specified WMI object. Select "Connect" and enter namespace information on the following form:



As you can see, we have selected CIMV2 which have required WMI objects we would be accessing shortly. When you select namespace, it is selected on the main form as follows:



Since we are connected to the required namespace, we can write queries for any object in this namespace. As you might know, the names of WMI objects traditionally start from "win32_". Here we are accessing information from WIN32_COMPUTERSYSTEM object.



We have written following WQL query:

Select * from win32_ComputerSystem

If you provide a valid WMI object then the result gets loaded. Otherwise, it results in weird exception messages.



You can view the properties of the object by double clicking the query result item. In our case, the properties are as follows:



In this way, we can select the properties of any WMI object.

Virtual member call from constructor of Base class

As we know virtual members are provided for providing late binding during polymorphism. This makes sure that those members are executed which are from the current object. If it is an object of parent class then parent's definition is used otherwise in case of child class's object, its own definition is used. The weird condition happens when we call this virtual method from constructor of base class. Let's look at the following code:

namespace ConsoleApplication3
{
class Program
{
static void Main(string[] args)
{
B obj = new B();

}
}

class A
{
public A()
{
Console.WriteLine("A's Constructor");
myMethod();
}

protected virtual void myMethod()
{
Console.WriteLine("A's member executed");
}
}

class B : A
{
public B()
{
Console.WriteLine("B's Constructor");
}

protected override void myMethod()
{
Console.WriteLine("B's member executed");
}
}

}

In the above code, in base class constructor, we are calling virtual member myMethod(). Since we are instantiating B, B's definition of myMethod would be used and you should observe the following output:


A's Constructor
B's member executed
B's Constructor

Some of you might be thinking why we are able to call B's implementation even when it's constructor hasn't yet been executed. Well it is just because object initialization is different than execution of constructor. Constructors are executed downward in specialization hierarchy but the direction of object initialization is opposite to this.

You might still not be able to find out any issue with this. The issue is when child's overriden member uses some of it's own instance fields. Let's see this in an example:

class B : A
{
string testString;

public B()
{
Console.WriteLine("B's Constructor");
testString = "Child string";
}

protected override void myMethod()
{
Console.WriteLine("B's member executed");
Console.WriteLine(testString.ToLower());
}
}

Here we have introduced a string, named testString in child class B. We are accessing this member in virtual method "myMethod". As soon as the control reaches the second line in myMethod() in B, it results in an exception.



Now it is a genuine requirement to allow child class to initialize it's members. In order to allow that, we might provide another virtual method which is executed before the required virtual member in the following manner:

namespace ConsoleApplication3
{
class Program
{
static void Main(string[] args)
{
B obj = new B();

}
}

class A
{
public A()
{
Console.WriteLine("A's Constructor");
initializeMembers();
myMethod();
}

protected virtual void initializeMembers()
{
}

protected virtual void myMethod()
{
Console.WriteLine("A's member executed");
}
}

class B : A
{
string testString;

public B()
{
Console.WriteLine("B's Constructor");
testString = "Child string";
}

protected override void myMethod()
{
Console.WriteLine("B's member executed");
Console.WriteLine(testString.ToLower());
}

protected override void initializeMembers()
{
base.initializeMembers();
testString = "Updated child string";
}
}
}

Now everything works fine. Not only we are able to access child class members but we are also able to initialize them before its constructor execution. Though this work around provides a workable solution, it is not recommended to use virtual members in constructors unless the class is itself sealed or the member is sealed. This would prevent the resulting exception. This is why most static analysis and productivity tools including ReSharper warns in this situation.

Tuesday, June 15, 2010

Getting control information from DataTemplate in ItemsControl

Sometimes we use ItemsControl to show a list of data when we don't want the added features provided by its various subclasses. But the problem is when we use data templates with ItemsControl. It seems impossible to get the info about the control and all information it provides seems to be about the data object it is mapped to, even when we have used specific user control in data template. It is generally required to get the information about this control to do some other things with this, like calling another method, use a property etc. Let's discuss how can we get that.


We create a Student class with two properties: StudentID and StudentName.



Now we create a user control with name StudentView with following XAML code:

The code behind of the control is as follows: (Please notice notifyMe method added)



Now we create ViewModel of the CourseView. We need to display a list of Students in CourseView. The definition of CourseViewModel is as follows: (Here we have created an observable collection of Students.)



Now comes the real CourseView. You might notice the ItemsControl. In ItemsControl, we have created a DataTemplate to show the information about different Student objects by using StudentView user control. We have also created a button. We will be using Click event of this button to get information about the elements in ItemsControl.


Now comes the real CourseView. You might notice the ItemsControl. In ItemsControl, we have created a DataTemplate to show the information about different Student objects by using StudentView user control. In the CourseView constructor, we have instantiated our ViewModel. I am in no way suggesting that this is the best approach for interaction between your views and view models but to keep the length of this discussion limited, I want to keep it direct. The interesting part is Button_Click (click event of the button in CourseView). You can see that we have iterated through the elements of myStudents ItemsControl. To get the information about the control, we have to use VisualTreeHelper. There is one important thing, you must be familiar with the visual hierarchy of the view, which generally is not an issue.