After reading your first post a few times I think I have figured out your message.
In the first code block you are describing my error in the OP and providing the Whys of the situation.
In the second code block you are describing the techniques used to access the various components of the object. I did not ask that, but you provided it as a necessary bonus.
Please comment and confirm/deny my interpertation.
Edit: I addressed this to a) recognize him specifically, b) identify the post. However, every reader is invited to respond.
You are welcome! However the cast to (char*) is barely an access of subcomponents, its rather accessing the contents of the object as binary byte array that should be considered as a primitive form of serialization. It might not work if you share the binary data for example between two machines that are different in endianness or if the class/struct member alignment used by the compiler of those systems is different and you don't set alignment explicitly (that isn't always possible)...
Note: In a simple program that isn't crossplatform its okay to serialize data this way. Lets say you write an exe that communicates over sockets with other machines - if all the machines run windows and you copy the same executable to all machines then everything will be fine, it would be a mistake to overcomplicate your serialization in this case. However the problem I wrote about (endianness, alignment) arises much often on linux platform where the underlying machine architectures can differ significantly and the same program has to be recompiled.
There is nothing you can do since there is no direct back link from the Windows handle to the class object. You will have to modify both your exe and your DLL to pass the pointer across from one to the other.
One of these days I'm going to think of a really clever signature.
Environment Windows 7, Visual Studio 2008, MFC, C++
Goal: create an asynchronous server and client class to demonstrate a simple server client operation. Base class for Server and Client is CAsyncSocket. IP address 127.0.0.1, port 49000
Status: The dialog has buttons for the server to Initialize, Listen, and Accept, so far. It also has buttons for the client to Initialize and Connect. Both have Close buttons. One dialog but two separate classes. Umm, make that three counting the CAsyncSocket class used by the server to communicate after the two have connected.
In the server group buttons Initialize and Accept appear to work correctly, in that order of course. The returned status is TRUE and wsa error code is zero. The Listen button creates a new object to handle the transactions and gets WSA code 10035 WSAEWOULDBLOKC, would block, treated as an expected result. Good so far. Now, hopefully, the server object is waiting for the client.
Then the buttons for the client are selected to Initialize, wsa error = 0, then Connect to the same IP address and port. It gets wsa error code 10048, WSAEADDRINUSE, address already in use. Hmmm. Yeah, it is in use, but if it is not in use by a server then the client cannot connect.
I believe I have the code working as I expect, but there is a fundamental error in my logic. Is this sufficient info for someone to tell me what I have done wrong or omitted? What might that error be?
Thanks for your time
Last Visit: 31-Dec-99 18:00 Last Update: 10-Mar-14 10:15