Regarding your user name: Any connection to "Knaverlisa" ?

ahz wrote: Wrong. That's barely above poverty level in San Jose! That's what they say - it's probably a lie :-)

knave45 wrote: if (!CryptAcquireContext(&hCryptProv, NULL, MS_ENHANCED_PROV, PROV_RSA_FULL, 0)){ CryptReleaseContext(hCryptProv,0); return GetLastError(); } You are trying to acquire the handle to key container "Microsoft Enhanced Cryptographic Provider " with the parameter MS_ENHANCED_PROV . The 9x system may not be having this key container with it. So try to get handle to some other key container. Or use NULL to get the handle to the default key container. If you don't like defaults !! try MS_DEF_PROV which is there with all window flavors i guess... -- Best Regards Suhredayan suhredayan There is no spoon.

Sounds more like a firewall/network problem to me. Where is the server located? Is it accesible from your friend's PC?

Hi KnaveD, I would like to interpret the following your statement.. LPVOID ptr = (LPVOID)((ServerData)m_serversList[pNMIA->iItem]); I can assume that m_serversList[pNMIA->iItem] returns the ServerData object from an array of m_serversList. If you look at your typecasting, it seems to be, it is returning a temporary object, which you are typecasting to a void. That object is not at all a pointer!!!! Solution --------- If I am not wrong, you can modify your code like this.. LPVOID ptr = (LPVOID)((ServerData*) &m_serversList[pNMIA->iItem]); ie to get the address of the array element.. " Action without vision is only passing time, Vision without action is merely day dreaming, But vision with action can change the world " - Words from Nelson Mandela Thanks & Regards, Gopalakrishnan

You are Da Man!!! A million thnx!!! Have you just tried returning FALSE instead of other processing, as per this note... Maybe with the improved handler (using the IsDialogMessage) you don't need to call DefWindowProc. Originally I was returning FALSE, but was not using IsDialogMessage. Hope that this helps someone in the future.

Thnx to both of you.... Sorry for the late reply Sorry for not properly specifying, but by locking up i ment the infamous " has encountered a problem and needs to close" was poping up. For further clarification on what causes this lock up, this occurs anytime I click on the window of the app (mIRC) that calls my dll or move the mouse into my dialog's window. Anyways, after using DefDlgProc, this problem goes away, but the calling app (mIRC) immediately terminates without notice. Any ideas?

Knave777Wave wrote: Do i need a Class or struct that encapsulates all the data and pass a ptr of it to the function? that's what i usually do. Knave777Wave wrote: Then what about my functions that i need to call from within my thread function... should these just go inside the 'Test' struct that my thread function is in... or are they something like static members of my data class? they can go wherever you like. there's really nothing special about the functions a thread calls. maybe you want to keep them in the same file as your thread function for ease-of-maintenance, but it's not strictly necessary. Image Toolkits | Image Processing | Cleek

Under the documentation of the recv function: "If the connection has been gracefully closed, the return value is zero". I'm assuming this would mean that the server has closed the connection. As to if this a correct or not assumption I don't know. It doesn't sound pretty dumb, that is definitely a challanging and rewarding way to learn. If you still have problems with your recv, then I would suggest creating a server which emulates the behavior of the real server, and determine if you can send empty packets, and what happens when you close down a connection. Greba, My lack of content on my home page should be entertaining.