Going Crazy: Trying to inherit an interface from another dll
-
Before I get started, I should warn you that most development I have done has been in VB. Now that the laughter has subsided, here is the problem: I have the following: IBaseData - An interface in a dll which will not contain any implementation code. ISybaseData - An interface which I would like to inherit from IBaseData INSTEAD of IDispatch. I get an error that says unresolved type declaration IBaseData in the SybaseData project. Does anyone know what I am doing wrong? EDIT: The SybaseData dll has a static link (#import) to BaseData project. Is that wrong? Note: When I have BOTH interfaces in the same project, and I hack around the .idl file it works fine and I get the desired effect. But when I try to inherit it from another project (dll) I get that error. Goal: To be able to do have a client app have a static link to the BaseData dll. After I create the smart pointer, I can then load by Classname "SybaseData.MyData" onto the smart pointer because they export the same functions, but a different implementation. In the future, I would like to create a "OracleData.MyData" dll and so forth and so on. Am I going about this the wrong way? I would rather not do use Invoke because it is a pain to set up. Please let me know if you need any clarification, as the entire post is probably a bit confusing ;)
-
Before I get started, I should warn you that most development I have done has been in VB. Now that the laughter has subsided, here is the problem: I have the following: IBaseData - An interface in a dll which will not contain any implementation code. ISybaseData - An interface which I would like to inherit from IBaseData INSTEAD of IDispatch. I get an error that says unresolved type declaration IBaseData in the SybaseData project. Does anyone know what I am doing wrong? EDIT: The SybaseData dll has a static link (#import) to BaseData project. Is that wrong? Note: When I have BOTH interfaces in the same project, and I hack around the .idl file it works fine and I get the desired effect. But when I try to inherit it from another project (dll) I get that error. Goal: To be able to do have a client app have a static link to the BaseData dll. After I create the smart pointer, I can then load by Classname "SybaseData.MyData" onto the smart pointer because they export the same functions, but a different implementation. In the future, I would like to create a "OracleData.MyData" dll and so forth and so on. Am I going about this the wrong way? I would rather not do use Invoke because it is a pain to set up. Please let me know if you need any clarification, as the entire post is probably a bit confusing ;)
If I am understanding your question correctly, you want to derive your new class from an existing interface. This interface exists in a separate DLL with a type library. Currently you are going to create one implementation of this interface, called SybaseData, inthe future you may create a different version of that interface called OracleData. With that out of the way, either way that you are doing it is valid. If you use the #import statement in your IDL file, it will create the interface definitions automatically for you and make them available to the MIDL compiler. Alternatively you could redeclare the IBaseData class yourself in your IDL file. As long as the guid matches and the interface is identical that method is valid as well.
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life! -
If I am understanding your question correctly, you want to derive your new class from an existing interface. This interface exists in a separate DLL with a type library. Currently you are going to create one implementation of this interface, called SybaseData, inthe future you may create a different version of that interface called OracleData. With that out of the way, either way that you are doing it is valid. If you use the #import statement in your IDL file, it will create the interface definitions automatically for you and make them available to the MIDL compiler. Alternatively you could redeclare the IBaseData class yourself in your IDL file. As long as the guid matches and the interface is identical that method is valid as well.
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life!Incredible. Thanks for the quick and informative reply, kilowatt. The odd thing is that the #import IS indeed in my idl file and I still get "unresolved type declaration". The second method (which I didn't think of) should work, but I would really like the first method to work if possible. Also, is this the "right" way to write a data abstraction layer? I would rather not have different rdbms code comingled in the same dll and unfortunately for this project, stored procedures aren't available. EDIT: The #import is pointing to the BaseData.dll, if that helps. Thanks in advance.
-
Incredible. Thanks for the quick and informative reply, kilowatt. The odd thing is that the #import IS indeed in my idl file and I still get "unresolved type declaration". The second method (which I didn't think of) should work, but I would really like the first method to work if possible. Also, is this the "right" way to write a data abstraction layer? I would rather not have different rdbms code comingled in the same dll and unfortunately for this project, stored procedures aren't available. EDIT: The #import is pointing to the BaseData.dll, if that helps. Thanks in advance.
Does your BaseData.dll file have a typelibrary definition? That is the only way that the MIDL compiler will be able to extract the IDL definition for you new dll to use. A very easy way to tell is by referencing your BaseData.dll to a visual basic project. If VB finds the components or even interfaces inside of your dll, tehn it has a typelibrary. If you do not have a type library inside of your BaseDLL then you will need to add the definition at the bottom of your IDL file for it. One other way to do this is to import the IDL definition from your BaseDLL project if you used an IDL file originally. If you want you can email me with more info.
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life! -
Incredible. Thanks for the quick and informative reply, kilowatt. The odd thing is that the #import IS indeed in my idl file and I still get "unresolved type declaration". The second method (which I didn't think of) should work, but I would really like the first method to work if possible. Also, is this the "right" way to write a data abstraction layer? I would rather not have different rdbms code comingled in the same dll and unfortunately for this project, stored procedures aren't available. EDIT: The #import is pointing to the BaseData.dll, if that helps. Thanks in advance.
I am sorry, I have been leading you down the wrong path. You cannot import a dll in the IDL file, you can only import IDL, ODL and header files. So that will be your best bet. You can use the importlib() directive inside of your new type library, but the MSDN documentation recommends that you use the IDL file so that all of the items from the original file will be available to your app. If you rely on the data in teh DLL, you will only get what is in the type library (which this may also include all of the items in teh dll so it wouldn't matter). Either way I think that using the IDL file from your base project is prefectly acceptable.
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life!