Tutorial: Tokenization (manually)
March 26, 2015
Tutorial: VisualBug [Manual Usage]
March 26, 2015

Tutorial: Tracking (manually)

All you will need for manual tracking is the class constructor. Tracking has been made very easy since version 1.1 (Hydrogen Update). First of all it’s important to say what you can track. This depends on the CompatibilityMode you’re running BugSpy (VisualBug’s tracking engine). There are 5 options at the moment:

  • Properties: You can track normal .Net properties which is not recommended since this requires regular pulling of it’s value, possibly causing lags when tracking lots of them.
  • Fields: You can track normal .Net fields as well. The same applies as to properties, though.
  • DependencyProperty: You can track WPF DependencyProperties [WPF only].
  • DependencyPropertyKey: You can track readonly WPF DependencyProperties [WPF only].
  • DebugProperty: You can track VisualBug’s DebugProperties which are lightweight, field-based, generic properties which notify about changes. These are most recommended. They are being used just like DependencyProperties just that DebugProperties won’t need any DependencyObject and do store data in themselves.
BugSpy will support INotifyPropertyChanged based classes in the future. From then on tracking properties won’t require pulls anymore.

There’s the same pattern for any type you can track. All you need is to call Spy.Track() in it’s correct overload. Note that DependencyProperty and DependencyPropertyKey have to be used with care. This will be explained below in detail.

Tracking Properties

For .Net properties just use the overload Spy.Track(PropertyInfo, object, InstanceId, string, string). Because it takes a bit of code to get a PropertyInfo-object, we introduced a little extension method for type Object. This allows you to easily get PropertyInfo- & FieldInfo-objects without much of code overhead. All you have to do for this is to set a using-statement to VisualBug.BugSpy if you haven’t already. The class containing these extension methods is called ReflectionHelper.

Now just insert a tracking-call for each member you want to track inside your application. We will take the TestClass3 from our sample application in order to show this process. In this class we have these 3 properties:

Now we add these lines to the constructor:

As you see it’s quite easy and doesn’t take much of code. By using the GetProperty extension method you can easily get a PropertyInfo-object from your class’ type. Specify the property’s name, whether it’s static or not and if it’s public or non-public (internal, protected, private). Then pass through the instance (this) because you need the instance in order to get any value from that property and last but not least your InstanceId-object (if you’re using tokenization). If you don’t use tokens, you can leave the last one null.

You may have noticed that we don’t pass through the last 2 arguments (name and context). This is because we have marked those properties with the Monitor-attribute. BugSpy will automatically reuse these if a property is tagged with one. In this case it uses the name specified in the corresponding attribute and the context generated by the passed through InstanceId and the corresponding token for this class type.

You need to set the Monitor-attribute if you want use a different MonitoringType than ValueField!
It is recommended to use the Monitor-attribute. This makes your code compatible to the injection-mode. The injector won’t track your members if they are not marked with this attribute!

Tracking Fields

Tracking fields isn’t different than tracking properties. Just use the GetField extension method this time and you’re good to go. The same rules apply as for the property tracking code. This time just use the Spy.Track(FieldInfo, object, InstanceId, string, string) overload.

Once again you don’t need to set the Monitor-attribute. If you do so, the context and name will be automatically applied.

NOTE: This time it’s a static and non-public field. Make sure you use the right arguments for the reflection extension methods GetField and GetProperty or you will encounter an exception!

Tracking DependencyProperties

Tracking DependencyProperties only works in WPF-mode. If you’re running WinForm-mode you will get a NotSupportedException. For tracking these properties you need to use the Spy.Track(object, object, InstanceId, string, string) overload. You will need this for both readonly and non-readonly DependencyProperties. If you pass through a DependencyProperty-object in the first argument, you will track a non-readonly property. If you pass through a DependencyPropertyKey-object you will track a readonly property. Passing through any other object will result in an exception. The second argument is any object of type DependencyObject. Passing through any other type will again result in an exception.

For everything else the same rules apply as for properties and fields. Here is a sample from our test application VisualBug.Lab.Wpf (MainWindow):

It’s as easy as this. As you see it is getting easier with DependencyProperties. The easiest to use though are DebugProperties.

Tracking DebugProperties

Last but not least we will cover BugSpy’s DebugProperty. It’s an easy-to-use property-type which is based on the design of DependencyProperties with just one little change. Their data is being stored in themselves, not in a external object. They do notify about changes, though – which is very important and the best solution for tracking. Because they notify changes by themselves BugSpy does not need to pull the values periodically, saving a lot of CPU resources. Tracking only these properties would allow to track as much as VisualBug does support (the internal limit is currently 2,147,483,647 which anon should be enough for any project). Only if lots are being changed in very short time, it could end up having troubles or getting your application into lags. But normally this shouldn’t be the case in most applications. Moreover it is not recommended to track any member you have. Only the most important ones and those you need to change or monitor regularly.

Anyway. This is how it works. Just the same like with DependencyProperties you need to declare them. This is from our VisualBug.Lab.Forms sample (MainWindow):

NOTE: The second one (BooleanTest) is marked as readonly. It’s the same as in the DependencyProperty-based sample above, just a bit easier to use.

As you see, tracking DebugProperty-objects is the easiest possible way.


Now you’re good to go. Start you application and VisualBug and try it. If you have any problems or encounter any errors or issues, just contact us .

HTML Snippets Powered By : XYZScripts.com