Comments on Simple inter application communication

[aw27]

The example is nice, but since the HWND_BROADCAST message is sent to all top level windows in the system, lots of things can stale SendMessage and make the applications freeze for a long time after the first message.
SendMessageTimeout improves a little, but is not the solution.

Sure, some people may not experience any of these.

[hutch--]

Funny I have never seen the effect, I regularly run video processing software the run on 6 core, 12 threads and it does not effect software that I have written it into for years. I imagine this is what RegisterWindowMessage() is for, to add a private message into the system queue passing messages to all apps running on the system. I imagine it is possible to load a machine up so badly that you could slow down the messaging mechanism in the OS but the whole system would be in trouble, not just an app sending a private message.

[aw27]

Google search:
HWND_BROADCAST hangs

[hutch--]

In the case of any app that does not respond for whatever reason, SendMessage is synchronous so you can expect that result, if you know that can happen between two apps that communicate in that manner, use PostMessage which just dumps the message in the system message queue and does not wait. The example posted above is between two apps that don't hang and that pass messages between each other, how HWND_BROADCAST was designed to be used.

[aw27]

 

You may recognize 2 things (or possibly not):

1) This method is not in the list of usual Interprocess Communications methods.
https://docs.microsoft.com/en-us/windows/win32/ipc/interprocess-communications

2) Still you can send messages to windows (not always), in addition to WM_COPYDATA, but is not savvy to broadcast a message to hundreds of windows when the target is just one.
What I believe is more savvy is find the HWND of the window we want then send our Registered_Window_Message message only to it.

[hutch--]

An interesting enough article but it does not even mention using Send/PostMessage. In this context, it is a signalling method as any message sent can only pass 2 values. A vast amount of the data in that article does not apply to using HWND_BROADCAST as the posted example is not trying to message apps on other machines, across the network or any other external method.

ALA Win32.hlp SendMessage

Remarks
Applications that need to communicate using HWND_BROADCAST should use the RegisterWindowMessage function to obtain a unique message for inter-application communication.
If the specified window was created by the calling thread, the window procedure is called immediately as a subroutine. If the specified window was created by a different thread, Windows switches to that thread and calls the appropriate window procedure. Messages sent between threads are processed only when the receiving thread executes message retrieval code. The sending thread is blocked until the receiving thread processes the message.


Use something in accordance with the documentation and it works correctly. Anyone can do it the wrong way and fail but write 2 or more apps that use the documented technique and it all works as it should.

[aw27]

I have modified your files caller.asm and slave.asm, and using FindWindow to find the top Window in each application now all work fine.

[hutch--]

 

You can do it that way but the originals worked fine. I had a look at the mod and it works fine but what happens if you want to send a common message to multiple apps or instances, HWND_BROADCAST does this fine, your technique does not. I use this technique on things like QE that has multiple instances so I can shut them all down or change setting in all instances at once.

[aw27]

For signalling I use events on a separate thread.
As we have seen SendMessage may not work well with HWND_BROADCAST. There are a few other alternatives to SendMessage  which may work better, but never tested because for signaling I use events. 

[jj2007]

what happens if you want to send a common message to multiple apps or instances, HWND_BROADCAST does this fine, your technique does not.

You can use FindWindow plus WM_COPYDATA in a loop. For WinByTitle, I use EnumWindows, but that's a matter of taste. In any case, HWND_BROADCAST is kind of anti-social. I hate to agree with José but he's right

[hutch--]

 

> As we have seen SendMessage may not work well with HWND_BROADCAST.

What do you mean WE paleface ? The criticism being made here is of either API that can use HWND_BROADCAST, SendMessage() and PostMessage() and the solution to any problems in use is called "Programming[tm]". Simply recognising the difference between synchronous and asynchronous actions by the two APIs means the "programmer" has to understand the target for where they are pointing their message.

Now look at the solution that Jose came up with using FindWindow(), you need either a class name or the content of the title bar of the app that you want the handle from and there is no garrantee that you have either. When you need to broadcast a single message to a number of instances, Jose's method only works on the first one so you then have to do it again and again and again.

The enumerate technique that JJ mentioned will work OK as long as you have a method of storing all of the handles that meet the criterion in use but it is big, slow and clunky along side a single Send/PostMessage that does it all in one API call.

Now for any that have doubts about the efficiency of such a single API call, set up a SPY tool for a simple app and don't filter out any of the messages and watch it stream some massive count of messages fed to the application's default handler.

I see little value in scouring the internet to listen to people squarking about their stuff ups, just read the standard Microsoft reference material on SendMessage(), understand how it works and it is a fast and reliable technique designed to operate within the operating system. In my case I have been using the technique since 16 bit Win 3.0 and it never fails if you do it properly.

[jj2007]

See Raymond Chen: Remember what happens when you broadcast a message. Broadcasting may work, of course, but it remains an anti-social way of communicating.

[aw27]

What do you mean WE paleface ?

When we make programs for other people we need to pay attention when they say it does not work properly for them. Even if only 1% mentions that it is already important.
Since I don't have a weird system and other palefaces from the internet have the same problem this means that the solution is not good.
In addition, Microsoft is not recommending that solution. That solution is as good for interprocess communication as using the Registry to pass values or writing to a temp file and expecting the other process to read them. None of these is a sound solution.

[hutch--]

This is nothing exciting but it does show a lack of understanding on what is happening.

Suppose you broadcast the message
SendMessage(HWND_BROADCAST, WM_COMMAND, 100, 0);
What happens?

Now if you actually READ the Microsoft documentation for SendMessage() as posted above you will see that with the HWND_BROADCAST message you use the RegisterWindowMessage() API for a private message. Now differing from Raymond Chen's post, if you use the technique properly, it works as documented. As he said, you can send WM_COMMAND but why would you do so ? By making a private message, you dramatically narrow the range of apps that respond to the message.

You may now understand why I don't listen to this waffle and go to the source, Microsoft documentation. Anyone can stuff up normal code but the general idea is to fix it. Would you stop using CreateWindowEx() because someone somewhere made a mess of it ?

[hutch--]

 

> In addition, Microsoft is not recommending that solution.

Remarks
Applications that need to communicate using HWND_BROADCAST should use the RegisterWindowMessage function to obtain a unique message for inter-application communication.
If the specified window was created by the calling thread, the window procedure is called immediately as a subroutine. If the specified window was created by a different thread, Windows switches to that thread and calls the appropriate window procedure. Messages sent between threads are processed only when the receiving thread executes message retrieval code. The sending thread is blocked until the receiving thread processes the message.

Microsoft document the usage, usage is determined by the programmer.