Thanks mate. I have solved it but it is true that microsoft sould be abit more open about what can go wrong with csocket. Especially since it is the default class when using wizards

The gamedev tutorial is definatly a good place o start. The basic concept is as follows. You have an object (say a box) give the box a bounding box or sphere. Pass the center vertex position of the box through the projection pipeline (i.e. project it onto the screen, there are opengl matrices that can do this). This will give you the coords of the object in 2d screen space. You also have to find the screen space size of your bounding area (same kind of method) once you have these you can test the mouse coords against the screen space bounding area. That isn't the best explination ever but it's somthing to start on. I'll see if I can dig out the code to project into screen coords

All fixed, A great thanks goes out for the info. I had been thinking switching methods was an option but thought I was just bailing out on what could have been a simple bug. At least CAsyncSocket was simple to change to and I can't see any further issuses occuring. One last question what does OP mean? (Original Poster?). I'm quite new to actually posting on forums. I normally find my answer on someone else’s thread. Once again Thanks Tom

PS I am (the OP) quite experienced but you guys fell off the trail, the question was about the CSocket WaitMessage problem, NOT about how I can encapsulate an existing class. Keep it easy Tom

Hi again guys Your debate seems to be coming along nicely :). Using CAsyncSocket seems to have done the trick (although I still need to sort the asynchronous sending) It's still quite annoying that the CSocket seems unstable. It's possible it was my fault but all the debugging I did only lead to the conclusion it was a problem with CSocket. Think when I get the time I'll sort a proper wrapper for raw sockets. I did one long ago at university but time is of the essence at the moment. Keep the debate moving, it's the best way for people to learn. Cheers Tom

Thanks guys, your adivse is will definatly be used. I think my best bet is to re write. I've started looking at casyncsocket and it seems like I wont need much modification so I'll try that first. Thanks once again I'll keep you posted Tom

Hi I have a realy stange problem with a mfc networking application I am writing (I couldn't see a netwoking message board, and I think it's more of an mfc problem) Basically I have your standard central server and multiple clients. Clients can connect and run happily doing what they do for hours on end (tests have run for 15 hours no worries) but quite frequently the appliction will freeze at any random time(when this happens all connected instances server and clients also freeze) the cpu usage drops to zero and they do nothing. When I break the app in debug mode (server or client) the code is always waiting at the waitmessage point in the pumpmessage function //sockcore.cpp, PumpMessage function else { // no work to do -- allow CPU to sleep WaitMessage(); //STOPS HERE bPeek = TRUE; } The pumpMessage function is called when a non blocking socket is going to block. I've read a few articles about the pumpmessage function causing a freeze but they all say its for older versions (im using vs 2005). http://support.microsoft.com/kb/154649 Has anybody else had this problem or does anyone know a solution? Your help would be greatly appreciated, as I am currently pulling my hair out over this and getting no where. Tom Hogarth