SendMessage and PostMessage which one is better to use

message-queuemfcperformancesendmessagevisual studio 2010

searching the web for the difference between these two function calls, I've found that:

The difference between these two API calls is the way that they return control to the calling application. With SendMessage control is not returned to the calling application until the window that the message was sent to has completed processing the sent message, however with PostMessage control is returned to the calling application immediately, regardless of weather or not the sent message has been processes.

postMessage: Sends a message in the message queue associated with the thread and returns without waiting for the thread to process that messaage.

SendMessage: calls the window procedure for the specified window and does not return until the window procedure has processed the message.

PostMessage is a Asynchronous function where as SendMessage is a synchronous function.

Now the question is for my application ( which needs high performance ) which function is better to be used?

Note that I'm using MFC in visual studio 2010 and for this code:

CWnd *pParentOfClass = CWnd::GetParent();
pParentOfClass ->

I just have these functions for sending messsages:

PostMessageW
SendMessage
SendMessageW

More questions:
Can you tell me the difference between SendMessage and SendMessageW?

Best Answer

You actually already answered your own question by describing SendMessage and PostMessage.

SendMessage: Sends a message and waits until the procedure which is responsible for the message finishes and returns.

PostMessage: Sends a message to the message queue and returns immediately. But you don't know when that message is actually being processed. Therefore, if you should be expecting an answer from that processed message, you will most likely get it through a message as well.

It really depends which one to use, but the end results are pretty much the same, it's just about timing. Also, PostMessage is especially useful in multi-threaded applications, which allows you to safely communicate between threads via their created windows.

PostMessage or SendMessage that end with A or W are just indicators how strings will be interpreted, i.e. single or multibyte, respectively. The ones without the A or W ending are preprocessor macros and will delegate to whatever you're application is set up to.

Related Solutions

Javascript – Which “href” value should I use for JavaScript links, “#” or “javascript:void(0)”

I use javascript:void(0).

Three reasons. Encouraging the use of # amongst a team of developers inevitably leads to some using the return value of the function called like this:

function doSomething() {
    //Some code
    return false;
}

But then they forget to use return doSomething() in the onclick and just use doSomething().

A second reason for avoiding # is that the final return false; will not execute if the called function throws an error. Hence the developers have to also remember to handle any error appropriately in the called function.

A third reason is that there are cases where the onclick event property is assigned dynamically. I prefer to be able to call a function or assign it dynamically without having to code the function specifically for one method of attachment or another. Hence my onclick (or on anything) in HTML markup look like this:

onclick="someFunc.call(this)"

onclick="someFunc.apply(this, arguments)"

Using javascript:void(0) avoids all of the above headaches, and I haven't found any examples of a downside.

So if you're a lone developer then you can clearly make your own choice, but if you work as a team you have to either state:

Use href="#", make sure onclick always contains return false; at the end, that any called function does not throw an error and if you attach a function dynamically to the onclick property make sure that as well as not throwing an error it returns false.

Use href="javascript:void(0)"

The second is clearly much easier to communicate.

.net – Which method performs better: .Any() vs .Count() > 0

If you are starting with something that has a .Length or .Count (such as ICollection<T>, IList<T>, List<T>, etc) - then this will be the fastest option, since it doesn't need to go through the GetEnumerator()/MoveNext()/Dispose() sequence required by Any() to check for a non-empty IEnumerable<T> sequence.

For just IEnumerable<T>, then Any() will generally be quicker, as it only has to look at one iteration. However, note that the LINQ-to-Objects implementation of Count() does check for ICollection<T> (using .Count as an optimisation) - so if your underlying data-source is directly a list/collection, there won't be a huge difference. Don't ask me why it doesn't use the non-generic ICollection...

Of course, if you have used LINQ to filter it etc (Where etc), you will have an iterator-block based sequence, and so this ICollection<T> optimisation is useless.

In general with IEnumerable<T> : stick with Any() ;-p

Best Answer

Related Solutions

Javascript – Which “href” value should I use for JavaScript links, “#” or “javascript:void(0)”

.net – Which method performs better: .Any() vs .Count() > 0

Related Topic