Accessing a application defined DLL from sibling DLL gets no contructor available error C2512 (VC6.0).
-
I have successfully constructed my main application using DLLs. Now I want to access one sibling DLL from another DLL. I can compile and link using forward declaration of sibling class: class OpenHR__DLL_Tabs_COM_; However, when attempting to allocate memory for the class pSecondaryTab = new OpenHR__DLL_Tabs_COM_(); I get error C2512: ...' : no appropriate default constructor available. The DLL of interest can be used by the main application without a hitch. Any constructive help as always is appreciated. Thanks Vaclav
-
I have successfully constructed my main application using DLLs. Now I want to access one sibling DLL from another DLL. I can compile and link using forward declaration of sibling class: class OpenHR__DLL_Tabs_COM_; However, when attempting to allocate memory for the class pSecondaryTab = new OpenHR__DLL_Tabs_COM_(); I get error C2512: ...' : no appropriate default constructor available. The DLL of interest can be used by the main application without a hitch. Any constructive help as always is appreciated. Thanks Vaclav
Could you post the definition of
OpenHR__DLL_Tabs_COM_? :)virtual void BeHappy() = 0; -
Could you post the definition of
OpenHR__DLL_Tabs_COM_? :)virtual void BeHappy() = 0; -
I have successfully constructed my main application using DLLs. Now I want to access one sibling DLL from another DLL. I can compile and link using forward declaration of sibling class: class OpenHR__DLL_Tabs_COM_; However, when attempting to allocate memory for the class pSecondaryTab = new OpenHR__DLL_Tabs_COM_(); I get error C2512: ...' : no appropriate default constructor available. The DLL of interest can be used by the main application without a hitch. Any constructive help as always is appreciated. Thanks Vaclav
I'm not sure about your design here. A library provides services to the program that uses it. in general, a dll will not know about, or be able to use anything from a "sibling" dll. I would suggest reconsidering your partitioning into modules so that this is not necessary and you have better encapsulation. Try for independent, service providing modules. If this is not possible, than perhaps these groupings really shouldn't be dlls. Not necessarily a recommendation, but an alternative might be to make them static libraries. If this is really necessary, then you could have the first dll dynamically link to the second. (Only one way - I don't really think you want circular references.) Under some circumstances you might do something with callbacks or passing in a object.
Please do not read this signature.
-
I'm not sure about your design here. A library provides services to the program that uses it. in general, a dll will not know about, or be able to use anything from a "sibling" dll. I would suggest reconsidering your partitioning into modules so that this is not necessary and you have better encapsulation. Try for independent, service providing modules. If this is not possible, than perhaps these groupings really shouldn't be dlls. Not necessarily a recommendation, but an alternative might be to make them static libraries. If this is really necessary, then you could have the first dll dynamically link to the second. (Only one way - I don't really think you want circular references.) Under some circumstances you might do something with callbacks or passing in a object.
Please do not read this signature.
Thanks Avi. I think my "problem" is that I am looking at it from user , mechanical , point of view. The DLL s are "placeholders" for property sheets. I have a main property sheet with secondary property sheet underneath. In plain talk - I have a tab control with sub-tabs. I would like to keep them in separate DLL , and so far they are. But I am trying to link them because that is the way it looks to the user. This is where I am wrong, and I need to rebuild it so they are just accessible from the main application only. They are both “connected” to the document anyway and need to communicate only with the document. Avi , I appreciate your comments, you made me think about my wrong way of approaching this. You are very helpful. Thanks Vaclav
-
Standard MFC with AFX_EXT_CLASS macro added, using MFC default constructor: class AFX_EXT_CLASS OpenHR__DLL_Tabs_COM_ : public CWnd { // Construction public: OpenHR__DLL_Tabs_COM_(); // Attributes public: ....
What error is coming, when you try to place
OpenHR__DLL_Tabs_COM_ cTab;, please ? :)virtual void BeHappy() = 0; -
What error is coming, when you try to place
OpenHR__DLL_Tabs_COM_ cTab;, please ? :)virtual void BeHappy() = 0;Eugen, when I do this OpenHR__DLL_Tabs_COM_ test; I get this error: error C2079: 'test' uses undefined class 'OpenHR__DLL_Tabs_COM_' Anyway, check the following exchange with Avi. I am using the DLLs wrong. It can be done but it is not that simple. MSDN calls it "Mutual Imports". Here is the link if you are interested: "http://msdn.microsoft.com/en-us/library/fdy23fx6(VS.71).aspx" Thanks for your help. Vaclav
-
Eugen, when I do this OpenHR__DLL_Tabs_COM_ test; I get this error: error C2079: 'test' uses undefined class 'OpenHR__DLL_Tabs_COM_' Anyway, check the following exchange with Avi. I am using the DLLs wrong. It can be done but it is not that simple. MSDN calls it "Mutual Imports". Here is the link if you are interested: "http://msdn.microsoft.com/en-us/library/fdy23fx6(VS.71).aspx" Thanks for your help. Vaclav
I can not understand, how it can be possible, if you have placed
#include "..\HeaderOfTab.h"correctly... :-D (OK, I will read your link, thank you !) For example: I have implemented the following stage :) :TOOLDLL <- EDITDLL <- APPEXE -> TOOLDLLvirtual void BeHappy() = 0;modified on Tuesday, March 16, 2010 10:55 AM
-
Thanks Avi. I think my "problem" is that I am looking at it from user , mechanical , point of view. The DLL s are "placeholders" for property sheets. I have a main property sheet with secondary property sheet underneath. In plain talk - I have a tab control with sub-tabs. I would like to keep them in separate DLL , and so far they are. But I am trying to link them because that is the way it looks to the user. This is where I am wrong, and I need to rebuild it so they are just accessible from the main application only. They are both “connected” to the document anyway and need to communicate only with the document. Avi , I appreciate your comments, you made me think about my wrong way of approaching this. You are very helpful. Thanks Vaclav
You're welcome. Thank you for that link in your post to Eugen Podsypalnikov. I didn't know about that possibility.
Vaclav_Sal wrote:
They are both “connected” to the document anyway and need to communicate only with the document.
Sounds good to me. Being somewhat simple minded ;) , I prefer to keep things as simple and straightforward as possible. Keep in mind that you will also have to maintain what you create. I've found that locating a problem when data flow is passing between 8 components, as it does in some software I get to maintain, can sometimes be interesting. Another approach you might consider if you have to notify other windows of some action, but the document's UpdateAllViews() isn't appropriate, is to play "chain of command". Implement a custom message that is sent to the parent window for handling or rebroadcast to siblings of the originator. I've done this with mix-in classes for splitter windows to keep the panes in sync. This has let me reuse views on different tab pages with different - or no - siblings. Oh, I just noticed your reference to VC++ version 6. Are you aware that the dialect of C++ used in 6.0 is non-standard? You might want to consider shifting your development to a later version that is more standard conforming. Good luck.
Please do not read this signature.
-
I can not understand, how it can be possible, if you have placed
#include "..\HeaderOfTab.h"correctly... :-D (OK, I will read your link, thank you !) For example: I have implemented the following stage :) :TOOLDLL <- EDITDLL <- APPEXE -> TOOLDLLvirtual void BeHappy() = 0;modified on Tuesday, March 16, 2010 10:55 AM
Eugen Podsypalnikov wrote:
For example: I have implemented the following stage Smile : TOOLDLL <- EDITDLL <- APPEXE -> TOOLDLL
I believe that what Vaclav_Sal was trying was more like:
----------<---------| |
EDITDLL <- APPEXE -> TOOLDLL
| |
---------->---------In other words, he wasn't linking one DLL to the other, but was trying to have them use each other by virtue of his knowing that they were both being used by the same exe.
Please do not read this signature.