How to receive WM_USER messages from other applications in LabVIEW

[while_loop]

I'm trying to receive WM_User messages from LV and from non-LV applications. Using the VIs from NIs Windows Message Queue.llb
it seems to work with standard WM_messages only (e.g. 0x0200 WM_MOUSEMOVE). What I'm looking for is a way to receive
programatically sent messages (by SendMessageA from user32.dll) in LabVIEW.

Are there any ideas or hints?

Greetings

Steffen

[Jason_S]

Hi Steffen,

The queue should work with WM_USER messages. In fact, they were one of the primary motivations behind its development. Perhaps you can explain what messages your application is sending, and post your VI.

Jason

[while_loop]

Hi Jason    ,

thanks for your reply. My problem is still alive, so I attach 2 Test VIs. The Send-VI works, I can send my WM_User messages
to other (non-LV) applications and the triggered action will be performed. Looking for the reason of the receiving problem in
LabVIEW (WM_queue_Test1.vi) I have used Microsoft Spy to see if the messages will be received it seems to be allright.
But my messages didn't occur in the message queue. - So what is my mistake, or isn't there a way to receive WM_User messages?

I'm using LV7.1 (WinXP).

Steffen

[rolfk]

---

@while loop wrote:
Hi Jason    ,

thanks for your reply. My problem is still alive, so I attach 2 Test VIs. The Send-VI works, I can send my WM_User messages
to other (non-LV) applications and the triggered action will be performed. Looking for the reason of the receiving problem in
LabVIEW (WM_queue_Test1.vi) I have used Microsoft Spy to see if the messages will be received it seems to be allright.
But my messages didn't occur in the message queue. - So what is my mistake, or isn't there a way to receive WM_User messages?

I'm using LV7.1 (WinXP).

Steffen

---

It quite likely does work, but you do not want to compare hWnd to your message value of 0x401 but rather Msg. hWnd is the window handle of the window receiving the message, but Msg is the message code (WM_xxxxxx).

Rolf Kalbermatter

[Odd_Modem]

Yeah, I see what you are saying. Microsoft Spy++ shows that the receiver window is getting the user message, but the LabVIEW queue does not do anything, even though it is registered for the exact user event number (and compare to MSG instead of HWND). I think in your dll interface to SendMessageA all the input parameters should be set to U32 instead of U16. I am using W2K and MSVC++5. I wonder if this user event ever worked? The GUI events seem to work with the queue. I think the baseline for this project was LV5, MSVC++6 and WinNT. Maybe something has changed with security patches???

[rolfk]

---

@Odd_Modem wrote:
Yeah, I see what you are saying. Microsoft Spy++ shows that the receiver window is getting the user message, but the LabVIEW queue does not do anything, even though it is registered for the exact user event number (and compare to MSG instead of HWND). I think in your dll interface to SendMessageA all the input parameters should be set to U32 instead of U16. I am using W2K and MSVC++5. I wonder if this user event ever worked? The GUI events seem to work with the queue. I think the baseline for this project was LV5, MSVC++6 and WinNT. Maybe something has changed with security patches???

---

One other catch might be that LabVIEW itself is actually using a few WM_USER - WM_USER + 4 or so messages itself for asynchronous event messaging between different parts of LabVIEW, though those messages usually are only directed towrds the hidden main window. Maybe that it's internal message translation and distribution swallows these messages.

Rolf Kalbermatter

[Jason_S]

Sorry I've been out of the loop for a few days.

Odd_Modem: Your definitely correct about the send message prototype. Both hWnd and wParam should be 32 bit values. I'm surprised that the messages are getting anywhere and that SendMessage isn't borking.

rolfk: I don't think reception of the message should be affected if LabVIEW is using the messages. I'm going off of memory here, but the hook intercepts the messages before the original wndproc gets them. Of course, it could confuse LabVIEW, but that's a different issue.

Odd_Modem may be on to something with security patches, etc. His quote on the baseline being NT, MSVC6 and LV5 sounds about right.

while loop, have you tried using PostMessage instead of SendMessage? Does it work?

I'll try to find some time to look into this further before the week is out. (Of course, that requires booting into Windows, which I'm less inclined to do these days 🙂

Jason

[Jason_S]

The problem appears to be that the call to SendMessage is coming from the UI thread, which is the same thread as the target window. I'm not sure why this doesn't work. I don't see any clear reason for it in Microsoft's documentation on SetWindowsHookEx. However, it's simple enough to work around. Change the configuration of the call to SendMessageA so that it is reentrant, rather than running in the UI thread. Since, in general, the "other" application that is sending the messages will not be in the same thread, it shouldn't be an issue.

It's also not clear to me whether the misbehavior that while loop discovered is a new "feature" of Windows XP or 2000, or if it always existed. In general, I configure all of my DLL calls to be reentrant unless I have good reason not to do so.

Jason

[Odd_Modem]

I got it to work with PostMessageA, message 0x8000. It works with occurrence drive or polling drive. I used U32 for all the function inputs. I used the original dll and LabVIEW 7.1.1. This, at least, shows that it works between two windows in the same process.

[rolfk]

---

@Odd_Modem wrote:
I got it to work with PostMessageA, message 0x8000. It works with occurrence drive or polling drive. I used U32 for all the function inputs. I used the original dll and LabVIEW 7.1.1. This, at least, shows that it works between two windows in the same process.

---

Stupid me! Of course! SendMessage waits for the message to be handled and the return value of the message be provided by the target window before returning. Apparently Windows has some protection built into SendMessage to avoid deadlocks by checking if the target window message loop runs in the same thread as the one calling SendMessage and in that case reverts possibly to PostMessage for known WM_xxx messages and just simply returns for unknown messages. If it wouldn't do that you would end up blocking in SendMessage for indefinite time as it waits for the message to be handled which never will happen since the thread handling the message loop is blocking on SendMessage.

PostMessage always places the message in the windows message queue and returns immediately avoiding possible deadlocks in this way.

Rolf Kalbermatter