You can not pass a parameter to a button event handler. You have to gather the data in the handler - for example by querying textboxes/checkboxes/etc in your handler method.

Seemingly your only problem is that your method signature doesn't match. See the AFX_PMSG[^] signature. You method receives a PCTSTR parameter while a button event handler should be a method without any parameters.

In my client and server classes never inherited a common base class. They just used some common components/classes like a socket class, whatever. Often its cleaner and more correct to use composition than inheritance. Over-generalization is usually a bad thing that should be resolved later. I refer with this to the "Core" base class here. I guess "Core" here means a lot of things and you create an "is a" relationship with inheritance between Server and Core and between Client and Core, so basically your server "is a" set of a lot of things that means chaos. In case of simple programs its OK to have not so nice design but if you want to do it correctly then try to isolate components and features that can be correctly named and encapsulated into a class (like Socket). In my networked programs other components that often come to the scene are "Connection", "Channel", "Server-SideClientHandler" or whatever. So instead of inheriting from a common base class I think here its usually nicer to isolate common things into classes and just using those classes from both the server and the client. If I inherited from a common base class in this case than it would probably be a CApplication class or something similar in case of using a framework... Another little note related to naming convention (although this is a matter of taste): When I have complex names like C_TCP_API_Server I usually remove parts of the name and use them as namespaces. For example in case of C_TCP_API_Server I would probably use a C_Server class that is inside a TCP_API namespace. This is however just style, its up to you how to name and organize things your code. I've already worked on codebases where the usage of namespaces was forbidden as part of the coding conventions. /off Fun fact: In my experience the most dangerous classes in object oriented code often have these names: Something-"Manager", Something-"System", Something-"Handler", Something-"Core", ... :-D /on

I guessed Visual C because this message board contains mostly windows development related posts. If OP needs another platform then modifying the search parameters isn't difficult. RS232 is a topic for which you can find very good tutorials on any platform very easily just by googling. I think OP was simply lazy to try that before posting here.

http://lmgtfy.com/?q=rs232+visual+c+programming[^]

Exactly. On our internal network that is wired with terribly expensive switches it was possible to reach constant 100MByte/sec with good hardware and windows but some things had to be tweaked for that. The SO_SNDBUF and SO_RCVBUF socket options are definitely among these tweakable things, I used 1-2 megabytes if I remember right.

And how would you synchronize the hardware refresh period? I would drop this idea.

Here is that paragraph from the msdn doc: "When bWaitAll is FALSE, this function checks the handles in the array in order starting with index 0, until one of the objects is signaled. If multiple objects become signaled, the function returns the index of the first handle in the array whose object was signaled." This means, if your first handle is very active then your WaitForMultipleObjects() has good chances to return the first handle even if there are other similarly active signaled handles at higher indexes. You may not even notice this on a strong machines but this behavior may happen only on some slower machines with less cores... Even in that case it isn't really a "BUG", its just starvation that is about as hard to debug as timing related thread-sync issues. Although the paragraph in the msdn doc is not a warning underlined with multiple red lines it is something that can cause you a lot of headaches if your app starts to misbehave just in some special hard-to-reproduce circumstances.

Is it OK if I record it into mp3 format before mailing it to you? Maybe wav would be too large but today saving a few hundred megabytes is no big deal and it has a bit better quality...

The logic is correct as WAIT_OBJECT_0, WAIT_OBJECT_0+1, ... are basically a constants and with switch it is valid to select between constants. However if your application is a high data rate app then be careful with the "linear search" of the WaitForMultipleObjects() function! It is actually documented (check its msdn page) that this function always returns the FIRST signaled handle from the array. This means if you have a "hyperactive" handle near the beginning of the array then the rest of the handles at higher indexes will starve. One technique to defend against this is "rotating" items in the array (or maybe a more fair algorithm is moving the currently signaled handle to the end of the array...). In case of Overlapped IO I would rather suggest using an IO completion port (shortly: IOCP) that isn't hard to plumb on top of your existing overlapped code, the difficult part is the overlapped IO that is ready in your case.

Just do what CPallini recommended. If you would do the same on linux then you could easily do the same trick with fork() without using 2 binaries.

Sorry, it seems I sent my previous post as a reply to the wrong place. :-)

Overlapped vs Async: I guess you have already programmed multithread apps for windows. Then you have probably met some synchronizations objects like CritcalSection, Mutex, Slim RWLock, ... Do you see, here MS used basically synonyms to differentiate lock types provided by the OS. Generally we could say that all of these are mutexes if we use the word "mutex" out of the context of the windows api documentation but the winapi documents use the word "Mutex" to refer to one of the winapi locks (the one created by CreateMutex) that can have a name and can be shared between processes in return for some performance penalty. After the previous paragraph it will be easier to understand the following: In the socket api docs MS uses the word "async" and "asyncblahblah" to differentiate a set of its socket handling apis from the rest of the apis. Usually with "async" the MS docs refer to the socket handling apis that send you completion callback as a window message (WSAAsyncSelect) but sometimes some docs also use "async" to refer to the bsd compatible select() function call and its more effective windows "equivalent" WSAEventSelect+WSAWaitForMultipleObjects or WSAPoll. But this is true only if we are in the context of the windows api docs and this is quite confusing. If we use async outside the context of the socket winapi docs then we can say that overlapped is also an async operation, the winapi docs just use "async" and "overlapped" to differentiate two different set of apis, its still very confusing as an overlapped operation is also an async operation. I guess this unfortunate naming convention probably comes from the fact that the original "async" api existed earlier than the overlapped stuff. If you search for "asynchronous" you will find a lot of explanations and some of them are so theoretically so abstract that they are totally impossible to practically interpret in my opinion. Here is a very dirty and rough explanation what async means when it comes to programming: An operation is async if it can be started without blocking the starter thread after starting the operation. The thread just starts the operation and later this thread or another one can poll whether the execution has ended or there is another more effective way to detect the operation finish: waiting for it. There is another mechanism to detect the operation finish event: a callback is called by a separate thread when the operation has finished but the pure waiting and the callback can be converted one to the other with user code so they are basic

You don't have to "switch", you can learn both. Try java too. Currently I'm working with C++ but worked with java for many years. The java language is extremely simple, not comparable to the complexity of C/C++. In case of java the hard work is rather learning the standard library and optionally j2ee related libs and a few opensource frameworks used by companies.

My opinion is that C++ looks ahead for a long future. C/C++ has probably the largest opensource codebase and set of libraries available (this is very important!!!) and most of the popular operating systems has been written in this language. (I'm a bit sad that some things can't be changed in C/C++ because of backward compatibility problems...) C/C++ is probably the "most portable" language across current popular platforms (Windows,Linux,Android,iOS,MacOSX,...) - try to run java on iOS... Even the android based java is a nonstandard one. Java and C/C++ are very different in many aspects, there are fields where they are simply not competing because either only Java or only C/C++ is the good choice. A serious programmer has to know C/C++ because currently "half of the world" has been written in this language and besides this you have to know many other languages anyway even if you don't actively using them. Your question is often the concern of newbies. They are afraid of investing their time in learning something because they are afraid of "putting up everything on learning a specific language". It is not the knowledge of a language that is valuable in a programmer. You can learn programming, program design and/or a paradigm by learning any of todays langauges. Being a good valuable programmer has nothing to do with knowing a specific programming language.

Not really. In order to understand volatile you should first understand some other concepts like multithreading and caching and all the related problems that can cause problems along with the optimizations done by the compiler.

// global scope. some other threads may use this pointer after its initialization...
int* globalptr;

void myfunc()
{
volatile int localvar = 0;
globalptr = &localvar;
//blah blah
//wait for something

// start using the volatile var again:
printf("localvar: %d\\n", localvar);
// In this case the compiler is forced to read up the value of
// localvar again from memory even if it would be present in a register.
// Maybe the compiler is smart enough to figure out that forming a pointer
// to the local var is suspicious but even if you hide this from the compiler
// with some ugly magic it will read the value from the memory when it comes
// to printing/using it without doing any optimizations/caching.

}

Then we agree, in this case some kind of memory fence is used for synchronization that is usually built into the synch primitives like events. In this case you usually make a function call too to pass the job to another thread and usually this already prevents a compiler from optimizing away some things.

If you pass a pointer to your variable outside the function (for example to an interrupt handler) and then you guarantee the lifetime of that variable (for example by blocking on an event with this thread) and you want to use the variable in the function after finishing the block operation on the event then it could be useful (because the value of the variable might have been changed by other threads) but what I've described previously sounds quite pervert and awfully designed code. I don't think volatile local vars to be useful.

You are right. Classic window messages (like WM_PAINT, WM_SIZE, ...) are all processed by the window proc of the control itself (that is window class specific). Specialized child windows (controls like Button, Edit, ...) are designed that they send only a few messages to the parent window (like WM_COMMAND message when the user presses a button, and WM_NOTIFY with control specific struct pointer). I guess this design was created because back in the old days people wrote their programs in procedural languages (C, Pascal) and in that case it is more comfortable to write just one windowproc for your window and to handle all child control messages there instead of writing a lot of window procs for all buttons, edit boxes, and so on... If you think about it, most of the core windows API is also a C interface. The irony here is that today GUIs are mostly built with object oriented GUI frameworks where one control is one object (I'm not talking about MFC here, that is at most 1/3 object oriented, Qt is a much better example). Such a framework needs to have/handle all control specific messages/notifications in the object associated with the control. For this reason the window specific implementation of such a framework usually delegates the handling of child control speicific messages from the parent object to the child object. Later the programmer usually registers an event handler into the object of the child control. You also need all control specific messages in the object associated with the child control when you want to write reusable specializations of some windows-builtin child controls (like static or edit).