Hello, at first I was thinking of just having each window class inherit from a base window class and implement a virtual window procedure, but I'd rather have a designated class that handles input. Ideally, I'd want to have something like allegro does with an event queue. I'm just not exactly sure of how I want to implement this. Any ideas?

Windows already gives your application an event queue which you're pumping from your main loop.

What exactly are you trying to accomplish? Having a base window class with a virtual message handler function is a perfectly valid solution that several class-based win32 wrappers use and works well for GUI-based applications.

I'm trying to separate the platform specific stuff from the actual game. I'd prefer the game to not even know what platform it's being run on so I want to separate the low-level input from the higher-level input.

And what I meant by having an event queue like allegro is that allegro takes the platform-dependent messages and converts them to higher-level messages that are pushed into a different event queue. Maybe that's not the best approach, I'm not entirely sure.

Let the platform-specific part translate the messages you are interested in into your own event struct, and give it a function pointer/object (platform-neutral code inside) to call when a event is generated.

Or just use some library to do this for you, for example, GLFW or SDL.

I'm trying to separate the platform specific stuff from the actual game. I'd prefer the game to not even know what platform it's being run on so I want to separate the low-level input from the higher-level input.

And what I meant by having an event queue like allegro is that allegro takes the platform-dependent messages and converts them to higher-level messages that are pushed into a different event queue. Maybe that's not the best approach, I'm not entirely sure.

Ok, so you're doing a game and not a GUI application. Then you aren't going to have several windows, so no need for a base window class with virtual dispatch.

I would suggest using a third party platform wrapper as wintertime suggested.

But if you want to do it yourself there are lots of ways of abstracting it, and different types of messages may need to be handled in different ways. Some messages like loss-of-focus and window resizing may want to be handled immediately, so you can do something like direct dispatch to a registered interface that wants those kinds of events. Input events can be more complex and you might instead want to put those into a queue for consumption by a time-stepped input system, or perhaps handed off and used to build a general "controller state" that the game will later query.

Especially with input events you won't want to do thinks like "is the W key held down?" you instead want "Is the MOVE_FORWARD control active?" to facilitate user bindings.

There are at least a couple of articles on this very site that go over how to handle input in more detail - for example, this one here. (I am not endorsing said article as better than any others, that's simply what popped up in a quick search)

Ok, so you're doing a game and not a GUI application. Then you aren't going to have several windows, so no need for a base window class with virtual dispatch.

I want to be able to support a UI in the future so that is why I was thinking of the virtual window procedure route. I suppose what I could do is have function pointers inside the window procedure that can be set externally via some member function, thus only implementing what I need to handle (IE, push button shouldn't care if an arrow key is pressed, etc). This way I can keep the reaction to an input event abstracted from the actual window that implements the window procedure.

Ok, so you're doing a game and not a GUI application. Then you aren't going to have several windows, so no need for a base window class with virtual dispatch.

I want to be able to support a UI in the future so that is why I was thinking of the virtual window procedure route. I suppose what I could do is have function pointers inside the window procedure that can be set externally via some member function, thus only implementing what I need to handle (IE, push button shouldn't care if an arrow key is pressed, etc). This way I can keep the reaction to an input event abstracted from the actual window that implements the window procedure.

You generally do not want to use multiple windows in a game project. Games almost always implement their UI in their own system decoupled from the OS. This is done largely for portability and speed. There are several OSes out there that do not support multiple windows (mobile OSes, all consoles) and full screen programs run faster than windowed ones (especially when SLI/Crossfire is involved).

If you were writing an editor, sure, multiple windows make sense. (And whether your editor should be embedded in your game or not is a whole 'nother discussion)

You might find some ideas here - https://www.youtube.com/playlist?list=PLEMXAbCVnmY4ZDrwfTpTdQeFe5iWtKxyb

Maybe this is helpfull after you have been familiar with what is on the link that SmkViper posted:

http://www.gamedev.net/page/resources/_/technical/general-programming/multi-threaded-keyboard-input-for-games-r3959

But basically you have input mapping and input re-mapping. The first one maps the raw inputs into the engine inputs and the second maps engine inputs to game inputs.

Hope it helps.