For years when I've been developing ArcObjects VB code to create a QueryFilter I have used the following to create the object:
Dim pQueryFilter As IQueryFilter pQueryFilter = New QueryFilter
I'm now redeveloping a 9.3 project into 10.1 using Visual Studio 2012 (VB). When I look at the code snippet examples I now see:
Dim pQueryFilter As IQueryFilter pQueryFilter = New QueryFilterClass
If one looks at the help file on IQueryFilter Interface it says only the class QueryFilter implements the IQueryFilter interface (as well as a bunch of other classes) but no mention of the QueryFilterClass.
If I change my code to use QueryFilterClass everything compiles as normal. So what is the difference, is there some reason why ESRI are showing snippet examples with this class? Is there some sort of performance issue?
Thank you for your reply. I've had a look at the links. I now know that QueryFilterClass is a managed class but I am unsure why one would create it? Is it best practise to now use a managed class for say memory issues? Why should I stop creating my QueryFilter class and start creating QueryFilterClass classes?
Duncan
The main reason I can see from the article is that the managed class contains internal XML descriptors that supports reflection so that when you attempt to get internal information about the COM object within the wrapper, such as TypeOf information, the information will be available to .Net. It appears that this reflection information is also important for casting to other objects, and that the unmanaged classes do not pass sufficient information to support direct casting and will cause an error.
Adopting the practice of using managed classes will make creating generic subroutines less error prone and improve your error testing and messaging abilities. They also give you more options in the generic subroutine to accept generic parent classes and branch to more than one child class when you want to perform operations that are useful across several different child classes, but that require different QI manipulations.
The managed class restores access to information in .Net that you would otherwise be unable to get. This informaton is easy to get in the native COM environment, but not in the .Net environment without the managed class, so using unmanaged classes will cripple this functionality for .Net. It may not be something you use everyday, but when you need to use it in order to revamp a large amount of code to enhance its functionality you usually regret not providing for it from the beginning.
"..All COM coclasses are converted to managed classes. Managed classes have the same name as the original with Class appended. For example, the runtime-callable wrapper for the QueryFilter coclass is called QueryFilterClass.
Dim pQueryFilter As IQueryFilter pQueryFilter = New QueryFilter
The inherited interface of a class interface is not guaranteed to remain the same between versions of ArcGIS; therefore, it is recommended that you avoid using the previous syntax.
All classes also have an interface with the same name as the coclass that corresponds to the default interface for the coclass. For example, the QueryFilterClass has a QueryFilter interface. The type library importer (tlbimp.exe) adds this interface so clients can register as event sinks. For more information, see the Class interfaces section ..."
Thank you for your reply. I've had a look at the links. I now know that QueryFilterClass is a managed class but I am unsure why one would create it? Is it best practise to now use a managed class for say memory issues? Why should I stop creating my QueryFilter class and start creating QueryFilterClass classes?
Thank you for your reply. I've had a look at the links. I now know that QueryFilterClass is a managed class but I am unsure why one would create it? Is it best practise to now use a managed class for say memory issues? Why should I stop creating my QueryFilter class and start creating QueryFilterClass classes?
Duncan
The main reason I can see from the article is that the managed class contains internal XML descriptors that supports reflection so that when you attempt to get internal information about the COM object within the wrapper, such as TypeOf information, the information will be available to .Net. It appears that this reflection information is also important for casting to other objects, and that the unmanaged classes do not pass sufficient information to support direct casting and will cause an error.
Adopting the practice of using managed classes will make creating generic subroutines less error prone and improve your error testing and messaging abilities. They also give you more options in the generic subroutine to accept generic parent classes and branch to more than one child class when you want to perform operations that are useful across several different child classes, but that require different QI manipulations.
The managed class restores access to information in .Net that you would otherwise be unable to get. This informaton is easy to get in the native COM environment, but not in the .Net environment without the managed class, so using unmanaged classes will cripple this functionality for .Net. It may not be something you use everyday, but when you need to use it in order to revamp a large amount of code to enhance its functionality you usually regret not providing for it from the beginning.
