The Inspectors share some features with Microsoft products and other tools.
We make no claim that the Inspectors compete with these products/tools, as they each have a different purpose. They are shown here only to help you understand their relative capabilities.
Browse method return value objects - Unlike other tools, the Inspectors represent objects in a tree form where the return value of a method invocation can be accessed fully and easily, just like any other object.
Show IList elements clearly - Consider the locals panel in the VS.NET debugger, its often difficult to find the contents of an ArrayList, because you have to be exposed to the internal implementation details of the class. Same with other classes that support the IList interface. The Inspectors simply present a list of objects, hiding the uninteresting details of the collection class implementation. Should you wish to see these details, there is an option to do so.
Show object names intelligently - The Inspectors show objects by name and try to pick the best name to represent the object. Sometimes this is the ToString() value of the object. Other times, if the object has a Name attribute this is used. This makes it a breeze to browse through a list of Form objects in Access for example, since the name of the form is shown as the name of the object. Compare this with the VBA property inspector.
Show correct ActiveX type information - The ActiveX Inspector reads all of the type information from the type library and is able to determine the correct ActiveX type of any ActiveX object where type information is known. It does this by understanding the relationships of the CLR types to the ActiveX types. It is far more effective at presenting ActiveX objects with the correct types than VS.NET.
(4) VS.NET supports both design and run mode of course. But it does not allow you to have the same instance of an object switch back and forth between design and run mode. In order to go into run mode, you must execute the code in a new process.