|
Hello !
Sorry for the late answer but it was the week-end  .
I also thought that having a static Destroy method could solve the problem but unfortunately not. If I specify Destroy as static and if I call this function from my executable:
CMyClass::Destroy();
it won't work neither  If I set a breakpoint inside the Destroy function, the m_pInstance member is NULL (resulting in a memory leak).
The only way that works is to have a global exported function in the dll that calls Destroy (the same way as the creating function):
#ifdef DLL_EXPORTS
#define DLL_API __declspec(dllexport)
#else
#define DLL_API __declspec(dllimport)
#endif // DLL_EXPORT
DLL_API CMyClass* CreateClass();
DLL_API void DestroyClass();
The DestroyClass function only calls CMyClass::Destroy(). If I do that, it works. But this not really what I would like.
Any idea of what's happening here and how to solve the problem ?
Thank you.
|
|
|
|
|
Cedric Moonen wrote: Any idea of what's happening here and how to solve the problem ?
Not really. I may work up a duplicate project structure so I can see this occur. I do have a question though. My question is based on the assumption that the singleton design does NOT produce this problem when contained in a single executable project correct?
Why do you need this design? Why do you need a singleton class to reside in a DLL? DLL's are supposed to be libraries. The requirement for the Singleton should be at the application level rather than at the library level so I am not seeing the benefit in this layout.
led mike
|
|
|
|
|
Hello, thanks for your answer.
led mike wrote: My question is based on the assumption that the singleton design does NOT produce this problem when contained in a single executable project correct?
I didn't test it but I'm almost sure that it works. Anyway, it works from within the dll without problems.
led mike wrote: Why do you need this design? Why do you need a singleton class to reside in a DLL? DLL's are supposed to be libraries. The requirement for the Singleton should be at the application level rather than at the library level so I am not seeing the benefit in this layout.
The thing is that I'm developping a 2D render engine (for games more particularly). There is a main class, the Engine class that holds several managers (for example a texture manager). It is much more convenient to have this class as a singleton so that I don't need to pass its instance to every class in the engine that requires the texture manager for example.
I would like also to have a "scene manager" that holds all the nodes that will be drawn at the screen. This class for example shouldn't be a singleton because you could have two scene managers (in games where you split the screen and have two slightly different scenes). So, the purpose here is to select the scene manager on which we working currently through the engine class (and have a method like GetCurrentSceneManager).
Does that make sense ?
|
|
|
|
|
Cedric Moonen wrote: Does that make sense ?
Maybe. You are designing a render engine into a DLL library to be used by different applications?
If so you need to keep the "singleton" design out of your library as I stated earlier. That type of "convenience" design should be in the application layer. This would simplify the engine design as well as provide a more flexible use model. The application layer code might or might not use a singleton wrapper for it's engine object depending on the application layer needs.
Perhaps the engine should be able to be built up, using it's interface, with it's constituent parts like the "texture manager(s)" and "scene manager(s)". Thus the engine can still have access to the managers it requires without being a Singleton. Then the application is responsible for these assignments. Responsibility == Flexibility.
led mike
|
|
|
|
|
led mike wrote: You are designing a render engine into a DLL library to be used by different applications?
The purpose will be to distribute the code afterwards. So I want it to be the most easier to use.
led mike wrote: This would simplify the engine design as well as provide a more flexible use model.
I don't think that will simplify the design: if I want some managers to be unique, then they will need to be singletons themselves (and I will have problems with the scene manager). The best case would be to have the engine as a singleton so that specific nodes can access the texture manager (for example).
led mike wrote: Then the application is responsible for these assignments. Responsibility == Flexibility.
That's not the way I would like to go. My plan is to have something very easy to use and still flexible (but the it should be first easy to use).
|
|
|
|
|
I am unable to reproduce the problem.
Here is the header file that is built into the DLL and distributed with the .lib file
<class t=""><class t=""><T>template <class T> class singleton{
protected:
static T* _pinstance;
singleton(){}
virtual ~singleton(){}
public:
static T& getInstance(){
if( !_pinstance)
_pinstance = new T();
return *_pinstance;
}
static void release(){
delete _pinstance;
_pinstance = NULL;
}
};
template<class T> T* singleton<T>::_pinstance = NULL;
class LOGLIBSINGLETON_API Logger : public singleton< Logger>
{
public:
Logger(void);
bool log( LPTSTR eventSource, DWORD dwEventID, WORD wCategory, LPCTSTR message);
public:
~Logger(void);
};
</T></class></class>
Then the application code uses it so
Logger::getInstance().log( msg, 0, 1, msg);
Logger::release();
with a breakpoint on the release call I step into the template source and the pointer is NOT NULL.
VS 2005 XP Pro SP2
led mike
|
|
|
|
|
The difference is in the fact that I have a global exported function in the DLL that creates the engine instance:
DLL_API CEngine* CreateEngine(....)
{
CEngine* pEngine = CEngine::GetInstance();
pEngine->....;
return pEngine;
}
The purpose will be that the end user will only work with an abstract Engine class (this function will in fact return the interface only). The user will be need to pass parameters to this function so that the Engine can be initialized with some specific parameters (that's the missing lines in the previous code snippet).
So, the instance is in fact allocated inside the dll, that's the main difference. The _pinstance member is only visible from within the DLL (it is NULL in the executable code). So, if in the executable code I call release, I will have a memory leak.
This works only if I had a global exported function in the DLL that calls release:
DLL_API void ReleaseEngine()
{
CEngine::release();
}
If I try to call CEngine::release directly from the executable code, the _pinstance member is NULL (I used the debugger to check) and I'll have a memory leak.
|
|
|
|
|
Well I added that new twist of the exported function but I still cannot reproduce your problem.
LOGLIBSINGLETON_API Logger& GetLogger();
LOGLIBSINGLETON_API Logger& GetLogger()
{
return Logger::getInstance();
}
Logger& logger = GetLogger();
logger.log( msg, 0, 1, msg);
Logger::release();
I don't understand why you need an exported function that just returns a pointer to an instance but that's just me. Ultimately it does not change the fundamental structure of what you are doing which is why it still behaves exactly the same for me.
IMHO if you need parameters to set up the engine instance you are back to what I orginally suggested anyway. Let the user create an engine and setup the engine using it's interface. If the user must supply these parameters what difference does it make how (what functions/methods) they use to supply them?
Or even add the parameters to the static getInstance(....) method. The global exported functions are zero added vaule as far as I can tell (however they do not seem to be the cause of your error since it works for me).
led mike
|
|
|
|
|
led mike wrote: Well I added that new twist of the exported function but I still cannot reproduce your problem
That's strange... What IDE are you using ? I'm working with VC2005 Express.
led mike wrote: I don't understand why you need an exported function that just returns a pointer to an instance but that's just me.
The reasons are multiple:
- First, I want to force the user to specify some parameters (like the screen size, and several other configurations). If I use several public function to do that it is not clean: some parameters are mandatory and I don't want the user to call 3 or 4 functions to initialize the engine. You said that I could add parameters to the static getInstance: that's quite bad. What happen if in my code, I want to access the unique instance ? I'll need to pass some parameters again ? That's not clean at all.
Remember that I want it the easiest to use for the end user.
- Second, I would like the user to work with interfaces only (so, pure abstract classes only) so, the Create function will in fact instanciate a CEngine class and returns an interface.
- I would like to have this code compile for several platforms (at least for windows and Linux), so having a DLL binary for windows and a 'dynamic library' (I don't remember the extension) for Linux based on exactly the same code. I know for sure that gcc can export functions, but I don't know if it can export classes.
- It could be interesting to have this dll to be explicitely linkable (so, using LoadLibrary and GetProcAddress). If you export classes, you can only use implicit linking (that is, using the lib file provided with the dll).
- I would like in the future that the dll can be used in other languages (for example in .NET). I don't know exactly how I will do that but I know more or less how COM components work: they have a global exported function that creates an instance of a class and returns an interface to this class. So, being able to use this dll in other language will require only to rewrite the interfaces.
So, there are several reasons why I want to keep this design.
Anyway, thanks for your help. I hope I'll find a solution to that problem.
|
|
|
|
|
Cedric Moonen wrote: What IDE are you using ? I'm working with VC2005 Express.
2005 Professional so I doubt that is the problem
Cedric Moonen wrote: If I use several public function to do that it is not clean:
I don't agree with that. The word "clean" is frequently abused in context of software design. If a user is going to use a "rendering engine" they can be assumed to be somewhat technical and should be capable of reading the documentation and sample code that details how to intiialize something as complex as a rendering engine. Have you ever worked with a 3D library?
Cedric Moonen wrote: but I don't know if it can export classes.
That is confusing since the "interfaces" you mention must be exported from your library correct? Therefore it is a requirement for you.
Cedric Moonen wrote: So, being able to use this dll in other language will require only to rewrite the interfaces.
Not sure if I agree with that. Native code is just "wrapped" by managed classes. You would use C++/CLI to create an assembly that implemented managed classes that wrapped all the native classes that you wanted to expose.
led mike
|
|
|
|
|
I think that I don't explain very well 
In fact, I would like to have something more or less similar to COM (except that it is much simpler: you just have one exported function that returns the interface of the engine).
led mike wrote: That is confusing since the "interfaces" you mention must be exported from your library correct?
No. They are interfaces and contains only pure virtual functions so in that case I don't need to export anything. By exporting I mean using __declspec(dllexport). Of course, header files of the dll still needs to be distributed but these headers contains only pure interfaces. It is the way COM components are working.
And thanks for your patience . I'll try to find what is causing the problem. Even if you are right, I still want to understand what is going on here (I don't like when I don't understand what's happening).
|
|
|
|
|
I had a cpp file for the library's DllMain implementation and I put the initializer in that.
|
|
|
|
|
I think the Rick York hint resembles mine: just put the static member initialisation in the DLL cpp (you should have one, at least it is not forbidden...)  .
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
Is it possible to enumerate the entry points a DLL exports (by name)? How?
TIA
ph
Developers, Developers, Developers, Developers, Developers, Developers, Velopers, Develprs, Developers!
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
Linkify!|Fold With Us!
|
|
|
|
|
Do you want to just do it yourself, or do you want to write a program that does it?
If you just want to inspect a DLL, use dumpbin from Visual Studio (actually just a wrapper around link.exe) or Dependency Walker[^] (also in the Platform SDK).
If you want to write a program to do it, see An In-Depth Look into the Win32 PE File Format[^] from MSDN Magazine.
|
|
|
|
|
the second link might do it (I was *fo course* hoping for some EnumDllExports Win32 API function..  ) - I'm gonna study this next week, thanks
Developers, Developers, Developers, Developers, Developers, Developers, Velopers, Develprs, Developers!
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
Linkify!|Fold With Us!
|
|
|
|
|
Hi,
I am experiencing some real trouble with a simple windows program that I am trying to create. After running the CreateDialog() function, windows returns the error "Windows class not created". I am having trouble determing what this message is really telling me.
The result of this error message is that after processing the WM_SETFONT message inside the DlgProc for the Dialog Box that it creates, Windows always processes the WM_DESTROY instead of the WM_INITDIALOG which is the next message that my other working windows programs processes which creates and displays the dialog box. I have posted my WinAPI function below:
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine,
int nCmdShow)
{
MSG msg;
HWND mainWnd;
hInst = hInstance; // Make instance available globally
InitCommonControls();
// Create a dummy window so the dialog box can have a parent window, then
// create the dialog box itself.
mainWnd = CreateWindow("", "", 0, 0, 0, 0, 0, NULL,(HMENU)-1, hInstance, 0);
MainDlgBox = CreateDialog(hInstance, MAKEINTRESOURCE(IDD_AURACONNECT), mainWnd, (DLGPROC)DlgProc);
DWORD Err = GetLastError();
SetClassLong(mainWnd,GCL_HICON,IDI_EXE);
// Standard Windows message loop
while(GetMessage(&msg, NULL, 0, 0))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
return msg.wParam;
}
I understand that I probably don't need to create a dummy window to create a dialog box. Also, I can't post my DlgProc because it is so large and long, but is this the most likely source of this error?
Thank you for anyone who can offer any help.
Joe
|
|
|
|
|
Can you post the code of the DlgProc?
Please use pre tags to post code:
<pre>
...your code here...
</pre>
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
<br />
<br />
LRESULT CALLBACK DlgProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)<br />
{<br />
<br />
switch(uMsg) <br />
{<br />
<br />
case WM_INITDIALOG:<br />
<br />
return TRUE;<br />
<br />
case WM_COMMAND:<br />
switch(LOWORD(wParam)) <br />
{<br />
<br />
case IDCANCEL:<br />
<br />
DestroyWindow(MainDlgBox);<br />
PostQuitMessage(0);<br />
<br />
return TRUE;<br />
<br />
case IDC_SETIPADDR:
<br />
SendDlgItemMessage(MainDlgBox, IDC_IPADDRESS, IPM_GETADDRESS, 0, (LPARAM)(LPDWORD)NewAddr);<br />
<br />
wsprintf(strAddr,"%d",NewAddr);<br />
<br />
SendCommand(&DataSocket, SET_IP_ADDRESS, sizeof(CommandStruct), messageFromHost);<br />
<br />
strAddr[cSetIP.length] = '\r';<br />
<br />
SendCommand(&DataSocket, strAddr, strlen(strAddr), messageFromHost); <br />
<br />
MessageBox(NULL,"IP Address has been changed sucessfully","Address Changed",MB_OK);<br />
<br />
return TRUE;<br />
<br />
<br />
case IDC_SETIPMASK:<br />
<br />
SendDlgItemMessage(MainDlgBox, IDC_IPMASK, IPM_GETADDRESS, 0, (LPARAM)(LPDWORD)NewMask);<br />
<br />
wsprintf(strAddr,"%d",ConnectAddr);<br />
<br />
SendCommand(&DataSocket, SET_IP_MASK, sizeof(CommandStruct), messageFromHost);<br />
<br />
strAddr[cSetMask.length] = '\r';<br />
<br />
SendCommand(&DataSocket, strAddr, strlen(strAddr), messageFromHost); <br />
<br />
MessageBox(NULL,"IP Mask has been changed sucessfully","Address Changed",MB_OK);<br />
<br />
return TRUE;<br />
<br />
<br />
case IDC_CONNECTBTN:<br />
<br />
WSAStartup(MAKEWORD(2, 0), &wsaData);<br />
<br />
SendDlgItemMessage(MainDlgBox, IDC_CONNECT, IPM_GETADDRESS,0,<br />
(LPARAM)(LPDWORD)ConnectAddr); <br />
<br />
wsprintf(strAddr,"%d",ConnectAddr);<br />
<br />
if(ConnectToSocket(MainDlgBox, &DataSocket, strAddr, DATA_PORT, WINSOCK_DATA_MESSAGE,FD_CONNECT|FD_CLOSE|FD_READ))<br />
MessageBox(NULL,"Connection attempt with AuraNET Headbox was sucessfull!","Connected with AuraNET",NULL);<br />
<br />
else<br />
{ <br />
if(MessageBox(NULL,"Connection attempt with AuraNET Headbox was unsucessfull!","Not Connected with AuraNET",MB_RETRYCANCEL) == IDRETRY)<br />
PostMessage(MainDlgBox,WM_COMMAND,(WPARAM)IDC_CONNECTBTN,0);<br />
<br />
else<br />
return TRUE;<br />
}<br />
<br />
EnableWindow(GetDlgItem(MainDlgBox,IDC_DISCONNECTBTN),TRUE);<br />
EnableWindow(GetDlgItem(MainDlgBox,IDC_SETIPADDR),TRUE);<br />
EnableWindow(GetDlgItem(MainDlgBox,IDC_SETIPMASK),TRUE);<br />
EnableWindow(GetDlgItem(MainDlgBox,IDC_GETSTATUS),TRUE);<br />
EnableWindow(GetDlgItem(MainDlgBox,IDC_CONNECTBTN),FALSE);<br />
<br />
<br />
return TRUE;<br />
<br />
case IDC_DISCONNECTBTN:
<br />
if(!DisconnectFromSocket(&DataSocket))<br />
if(MessageBox(NULL,"Attempt to disconnect was unsucessful. Press Retry to attempt to disconnect again, or Cancel to stay connected","Disconnection Failure",MB_RETRYCANCEL) == IDRETRY)<br />
PostMessage(MainDlgBox,WM_COMMAND,(WPARAM)IDC_DISCONNECTBTN,0);<br />
else<br />
return TRUE;<br />
<br />
<br />
WSACleanup();<br />
<br />
EnableWindow(GetDlgItem(MainDlgBox,IDC_DISCONNECTBTN),FALSE);<br />
EnableWindow(GetDlgItem(MainDlgBox,IDC_SETIPADDR),FALSE);<br />
EnableWindow(GetDlgItem(MainDlgBox,IDC_SETIPMASK),FALSE);<br />
EnableWindow(GetDlgItem(MainDlgBox,IDC_GETSTATUS),FALSE);<br />
EnableWindow(GetDlgItem(MainDlgBox,IDC_CONNECTBTN),TRUE);<br />
<br />
<br />
return TRUE;
<br />
<br />
case IDC_PAIR:<br />
<br />
SendCommand(&DataSocket, SETUP_PAIR, sizeof(CommandStruct), messageFromHost);<br />
<br />
return TRUE;<br />
<br />
<br />
}<br />
<br />
return TRUE;<br />
<br />
case WINSOCK_DATA_MESSAGE:<br />
<br />
WinsockHeadboxDataMessageLoop(MainDlgBox, wParam , lParam);<br />
<br />
return TRUE;<br />
}<br />
return FALSE; <br />
<br />
}<br />
<br />
Thank you for looking at this.
|
|
|
|
|
Sorry for the delay, but rebuilding a project with that code took a bit of time.
Anyway I don't get any error on my system, where CreateDialog works correctly.
However, MSDN recommends, for modeless dialog, the following behaviour:
while (GetMessage(&msg, NULL, NULL, NULL))
{
if (!IsWindow(hwndGoto) || !IsDialogMessage(hwndGoto, &msg))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
to avoid processing not-dialog messages (hwndGoto is the dialog HWND, in the above snippet). I don't know if that helps you.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
if you can build a project with no error on your system would you consider zipping it up and sending it to me/ posting it to see where we differ?
|
|
|
|
|
TheDelChop wrote: would you consider zipping it up and sending it to me
Yes, of course (by the way I need you e-mail address)
TheDelChop wrote: posting it
I don't know how if it is possible to post zip files via the forum.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
JDelCioppio@astromed.com
Thank you so much,
Joe
|
|
|
|
|
Did you try my suggestion in the reply to your other post?
Try changing
SetClassLong(mainWnd,GCL_HICON,IDI_EXE);
to
SetClassLong(mainWnd,GCL_HICON,LoadIcon(hInstance, MAKEINTRESOURCE(IDI_EXE));
|
|
|
|
|
Oops...
Should be
SetClassLongPtr(mainWnd, GCL_HICON, (LONG_PTR)LoadIcon(hInstance, MAKEINTRESOURCE(IDI_EXE)));
And your parent window has no window class registered for it?
Try making the dialog style overlapped and create it with parent HWND = NULL.
Mark
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
