   What's this error talking about?
  Just one error in this code:''__thiscall cInput::cInput(struct HINSTANCE__ *,struct HWND__ *)'' : cannot convert parameter 1 from ''struct HINSTANCE__ *(void)'' to ''struct HINSTANCE__ *''   There is no context in which this conversion is possibleSo I''m getting a pointer from one class to the HINSTANCE handle, but it wants a structure? How can I get around this? Here''s the setup I''ll be using for my game.   #include "Global_Header.h"int WINAPI WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd ){PtrMainApplication = new cSystemStuff;PtrMainInput = new cInput( PtrMainApplication->Get_hInst,   PtrMainApplication->Get_hWnd() );   PtrMainApplication->Run();return 0;}Thanks 
  You forgot your parentheses after ->Get_hInst  .  You''re trying to pass a pointer to a function with a declaration like so:struct HINSTANCE__ * Function(void)  That''s where the (void)   comes from in the error message.  Just make it ->Get_hInst()   and you should be good to go. ;  I don't know how to use my input class for a game. Here's my WinMain #include "Global_Header.h"int WINAPI WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd ){BOOL IsDone = FALSE;PtrMainApplication = new cSystemStuff;PtrMainInput = new cInput( PtrMainApplication->Get_hInst(),   PtrMainApplication->Get_hWnd() );   PtrMainApplication->Run();return 0;}It all works out great, compiles, and brings up a nice little window for me. But I don't know how to incorporate the input. I've seen some source that uses a ton of #define for like released, locked, pressed or whatever, and I don't know what that stuff means.Should I contain the input class inside of my cSystemStuff class, along with the future sound, and graphics classes? That's really my problem, I don't know how to combine the components. For example, what would I do in the WinMain file to get some input? PtrMainInput->Read(); That does me no good it seems. If I try to do any game stuff directly in cInput::Read(), like a bunch of if statements with all my keys that I'll use, I don't have access to any variables in the rest of my program. I could use friends I suppose.I would just like to figure out how I could make the program exit when the user presses the escape key. That's really all I'm trying to do right now and I have no idea how to do that.Someone please steer me in the right direction, because I know it's all about to "click".Thanks-Peter   [edited by - PoLiSh_Peta on February 18, 2004 8:09:18 PM];  Well, it largely depends on how you''ve defined your input class.  If, for example, you have a method called GetKeyState(int Key), then in your Run() method (which I assume contains the Windows message loop), you would call GetKeyState(VK_ESCAPE), and test to see if it is pressed.  If so, then you can quit your message loop, or call PostQuitMessage(0), etc.  That method is called polling.  The biggest problem is that if the escape key is pressed quickly enough, then between the previous and next time you call GetKeyState(VK_ESCAPE), the key will have been pressed and unpressed, and you''ll never know the difference.The other primary method is to keep a buffer of input events, inside the cInput class.  Internally to the class, whenever you see that an input event has occured, add it to the buffer.  Then, outside of cInput, such as, again, in your Run() method, you could call PtrMainInput->GetOldestEvent(), and it would remove an event from the buffer and send it to you.  You would then check to see what device it was from, which key, button, axis, etc., it was from, what the event was (KEY_UP, KEY_DOWN, CHANGE, etc.), and act accordingly.You could even take the event model one step further, and by either using callback functions, or thread-synchronization event objects, have the input class immediately inform you when an event occurs, instead of waiting until you call GetOldestEvent().  But that is probably more complex than what you need at the moment.  But it''ll be worth considering later on.Either way, your input class should never   perform game-specific processing.  All it should do is provide a standard form of communication between hardware inputs and your program.  You do all of your actual reactions to input from outside of the cInput class.Oh, and as for the cSystemStuff class, yeah, input is a part of the system, in addition to sound and graphics, so it would probably make sense to put it there.  So I''m guessing the structure is that the game code has access to a cSystemStuff class.  It can ask this class for cInput, cSound, cGraphics, etc.  Once it gets those individual classes from cSystemStuff, it can go ahead and use them.  That sound about right?Hope this helps. 