I''m running some code in a dll that might catch a state. That state is maintained as a static in the exe. What tactics could I use to communicate the state change to the exe? The real problem: The renderer lives in a dll (say opengl). Since the renderer owns the window it has registered the event handler. The eventhandler however is global to the application as the app control the global state(am i hybernating while minimised, or running normally). Now the problem occurs when the renderer in a different memory space attempts to say to the static application "your minimising, go in to hybernation mode". From what I''ve read static that are included in an exe and a DLL create seperate copies, hence even though in the debugger it looks like your updating a variable it the wrong one. I would have thought a singleton would help but a single is really just a nice wrapper around a static. Would putting my application state data on the heap help? Passing the pointer in to the renderer so it know where to find the one true CApplication ??? Is that how it''s done? Many thanks for reading this far (I''ve written this post and cancelled it three times in the last week, I can''t seem to be this one...) Chris

I''m not sure if I got you right.
Your aim in designing separate modules (dlls or exes) is to wrap different logical functionality - and to have a preferably small interface between them. You use this interface in both directions. This should already answer your question: just have a function in your dll that receives window states (communication from your exe to your dll) and vice versa.
You will never intend to design an interface to use some static code to share with another component. If you need to share some data, make it available to the other component (pass the pointer). It must be clear who has the ownership.

The easiest case: make a static dll und include it''s lib and interface header files in your exe (or other dll). Now you can "see" your classes and functions as if available in your workspace. To prevent chaos, you should minimize the communication between them and group your components around logical functionalities.

The drawback of such a technique is the overhead due to higher configuration management (dependencies, build order, interface design etc.)




- thomas

I believe I understand your problem, like Renus, but I''m a little iffy, so just ignore me if I go on a tangent about the wrong problem .

Basically, you have your main game in the EXE, and the renderer in the DLL. You want to have the EXE be able to access the DLL to get the renderer, and the DLL to access the EXE to tell it about a window state change, right?

Well it''s possible, as Renus said, to pass a pointer to the CApplication class to the DLL, but I think this is just getting around the problem (and creating others such as major dependencies), rather than solving the problem.

I think your problem is in bad design. I personally don''t think it''s a good idea to put your window initialization code in the renderer DLL for a couple of reasons.

1) If you are going to support multiple renderers then you''re going to be duplicating the windows code in each DLL (one for OpenGL, one for DirectX).

2) If you are going to support multiple operating systems then you''re putting OS specific code in an OS independent renderer (OpenGL). You''d have to strip out all Windows specific code to use it for Linux.

3) Other DLL''s may need access to your HWND, or HINSTANCE variables in the renderer. For instance, if you put your input code in a DLL as well (so you can use DirectInput, SDL, etc) then you will need to access the renderer DLL to get the HWND, and HISNTANCE to initialize DirectInput. The input DLL and renderer DLL should have NO dependancies between the two. Also, you shouldn''t require a 3d renderer just to use your input DLL.


Personally, I''d either put your window initialization code in your CApplication or derive a new class (CWinApplication) from CApplication and put it in there. Pass the HWND, HINSTANCE, or other window specific variables to your renderer and input DLLs. Remember, decoupling is a Good Thing.

If you design your game this way, then the renderer won''t need to tell the main application that the main application is being minimized. Instead, the main application is the one to detect the main application is getting minimized. Erm, did that make sense?


- Houdini

Cool. You both got the problem. I''ll have a little think about this and redesign. Good call regarding the requirement of hwnd to be global, I didn''t even think about that, and it would have bittem me down the track.

Thanks all.