   win32 - messages - creating an OO event system
  There is two basic ways on how to get an object to react on input. Eiter poll, og get polled.Polling is easy, but I don't want to create an application drawing 99% cpu if I can awoid it.I want to try an approach similar to Java and C#, where I create an function in the class that are to respond on input. This function should then be registered in an event object or some sort...The best thing would maybe to create a window object that contains the creation of an window(I usually either makes fullscreen, or basic windows anyway). Then I could pretty much just start my code by creating an object that derives from the window, and set some basic stuff to get it up and running.But how to deal with the good old win32 message system? I want to hide it as much as possible. If I want a particular object to react on a particula message or input, I want a clever way to do this, at the same time as easy and reusable as possible. If I want to add another input system like directX, or ... whatever ... I also want a good way for this.   
  Have you found PeekMessage() yet?  It lets you see if a message is in queue and if it is... dispatch it.   ;  Erh? you're leaving out a big amount of information Mike2343.GetMessage i think its called, will check the windows message que, and if there are no messages in the que it will put your application to sleep. If a message comes in well your application is asleep the windows message que will wake your applicaiton up and return 1 from Getmessage.PeekMessage on the other hand will not place your application to sleep, instead it will return control back to your applicaiton. But you need to remember to check WM_QUIT, because that is automaticaly handeled by getmessage.DarkSlayer I highly recommend checking out Visual Component Framework, its a good library that contains alot of usefull code. It contains the source code too so if you need to modifiy the code for your own unique feature its there.Unfortantly, I recommend you go through the win32 message system by following some of the tutorials on the internet. Your best to learn the gutts of windows API now, because alot of technology is based off this simple message que system. It gives your huge flexability in programing any type of solution you would want. Although for RAD its a real pain in the a***.Now just so i dont get flambed to death here is my reason for suggesting your learn the widnows API system now than later.No matter what API system you use, now or in the future. They all have to communicate with the underlying API system of windows. Now if you understand the hard core workings of the windows API system, your a) understand the limitations b) Can easly adopt any new API system that comes your way c) know how to build your own abstraction layer that mabe simplier than those on the market.   ;  @doodo: Actually I didn't leave anything out.  GetMessage is blocking and not what he wants.  PeekMessage will not block but will let you know when a message is ready for dispatch.  It's exactly what the OP needs without reinventing the wheel.  I didn't post much more because I expect people to have enough computer knowledge to open up a web browser, go to google, type in "PeekMessage +msdn" and find the rest of the information themselves.  He specifically said he didn't want something taking up 99% of the CPU, which is exactly what GetMessage will do.  Therefore it's not the solution he's looking for and therefore pointless to mention it and also likely what he is using currently.I have also found PeekMessage will handle WM_QUIT but most people check for it in their event handling loop so they can break out of it (what I do).  But either way should work.@DarkSlayer, depending on what what exactly you want to do, you may be better off learning WinForms.  But since you're only posting about input and just a bit about Win32 you really don't need that much knowledge to get a Window up and going to work with.   ;Quote:Original post by Mike2343He specifically said he didn't want something taking up 99% of the CPU, which is exactly what GetMessage will do.Wrong. GetMessage will put your app into a wait state, which draws no significant CPU.Quote:I have also found PeekMessage will handle WM_QUIT but most people check for it in their event handling loop so they can break out of it (what I do)."Handling" WM_QUIT here has nothing to do with choosing either PeekMessage or GetMessage itself; it's a function of whether you pass your window handle or NULL as the HWND parameter.   ;  @Mike2343np mike, thanks for the info. I couldnt exactly get all that info from one line that you place above so i thought i would just fill in the gaps :)Didnt know you could use +msdn to search in google. most helpfull.;Quote:Original post by OluseyiQuote:Original post by Mike2343He specifically said he didn't want something taking up 99% of the CPU, which is exactly what GetMessage will do.Wrong. GetMessage will put your app into a wait state, which draws no significant CPU.Darn you Oluseyi!  I realized I made this mistake about 2 hours after posting it but my wife was dragging me around town today.  Come home to edit my post and you already caught it.Quote:Quote:I have also found PeekMessage will handle WM_QUIT but most people check for it in their event handling loop so they can break out of it (what I do)."Handling" WM_QUIT here has nothing to do with choosing either PeekMessage or GetMessage itself; it's a function of whether you pass your window handle or NULL as the HWND parameter.Ah.  I still check for WM_QUIT in my main loop (it checks for Win32 events, if none calls my main game loop) just so I can break out of it easier.  But it doesn't remove the WM_QUIT message from the queue (just changes a bool).  Works well so far.@doodo: No problem, a friend taught me that about 2 years ago, makes life a whole lot easier :-)Edit: fixed some typos.   