Windows Message Queue 64-Bit Support

[madview]

Thanks anyway for replying 

[zou]

I would use MS Spy++ to make sure that the FP actually gets the message (WM_DEVICECHANGE) first.

[madview]

Hi Zou,

thanks for your reply.

I've done what you suggested and I can see the message being sent to my window.
Even though the message is recorded by Spy++ (64bit) it seems I haven't registered for it on LV. I used the code reported in the header
#define WM_DEVICECHANGE 0x0219
I guess I should use another one, but which one?

[madview]

One more thing. I'm able to register for left button mouse click events and catch them in LV using code 201.

When I looked at these kinds of events in Spy++ I can see that these (WM_LBUTTONDOWN) are reported as posts while the WM_DEVICECHANGE events are reported as Sent or Return. Could it be that we can register only to post messages using this method? But if that would be the case I shouldn't be able to run the same software in LV32bit and get the messages as expected. I'm quite confused.

[zou]

The 32bit version works, the 64bit version doesn't work.

Don't no why.

[rolfk]

Windows messaging can be confusing and there is even the possibility that the 64-bit version of the Window handling introduced additional security measures that could not be implemented in the 32-bit version due to the holy grail of backwards compatibility.

Posting a message means, throw it out to the window in question and forget about it. Sending a message means to send it and wait for the application to return with an acknowledgement that the message has been processed. So the according SendMessage() API is actually blocking!

There is also the possibility that messages are only sent to the main window of an application (this would be the always invisible LabVIEW root window).

One issue about sending messages may lay in this remark on MSDN:

Message sending is subject to UIPI. The thread of a process can send messages only to message queues of threads in processes of lesser or equal integrity level.

[madview]

Hi Rolfk,

thanks for your explanation.

I think I found the root cause of the issue even if I don't know how to properly solve it.

Debugging the DLL it seems that the order of the bytes in CWPProcessMessage for cpws->hwnd is swapped.

I've made a hack to solve it in my special case to shift the bytes and get the message I needed (x219 -> 537)

I'll post it here, maybe it could be useful to someone else.

at line 324 in "Windows Messages for LabVIEW MT.cpp"

while ((ei = EIL.GetNextQueueByMessage()) != NULL)
{

      if(cwps->message == 537) cwps->hwnd = (HWND)((int64)(cwps->hwnd) >> 32);

      if (ei->LVhWnd == cwps->hwnd)...

Now I have another issue though.

I'm using the occurence to fire events in another window but I'm not able to detect any message related to that window or the application exit, do you have any idea on how to detect that?

Could be it be that for the application exit is one of those cases where the message is blocked?

[rolfk]

Go into your project settings and change the structure alignment setting from 1 byte to default (8 byte) for at least the 64-bit builds.

First LabVIEW does not use non-default alignment on 64-bit Windows versions. It does use packed (1 byte) alignment on 32-bit platforms but that should NOT be resolved by changing the project settings either but rather by wrapping the declarations of structures that directly interface to the LabVIEW diagram with the 

//LabVIEW Array
#include "lv_prolog.h"
typedef struct {
	int32 dimSize;
	uInt32 arg1[1];
} TD1;
typedef TD1 **TD1Hdl;
#include "lv_epilog.h"

declarations. They take care if enabling the alignment according to the current build platform and reset it to the previous setting.

This should be all that is needed to be changed in the main cpp file and then you can remove the alignment in the project settings for all build targets.

In fact for this particular data structure, alignment is never an issue so disabling the non-default alignment setting in all builds should simply work. I still would edit the declaration of the type so that if someone ever decides to return some more information in that array handle, it will keep working independent of any alignment issues.

[madview]

Hi Rolfk,

thanks for your reply.

Adding that change in the DLL code did the job.

I'll leave it here maybe it could be useful to someone else.

I'm still having issues detecting the main window closing.

Do you have some suggestion for it?
I have registered for these messages but none of them seems to be reported.

x2 WM_DESTROY

x12 WM_SETTEXT

x16 WM_CLOSE

x18 WM_QUIT

x22 WM_ENDSESSION

[rolfk]

Those messages are likely not sent to every window but only to the main window that gets created during process startup. In the case of LabVIEW this is a hidden window, sometimes called the root window which is also LabVIEW's root loop and runs entirely in the context of the main thread, also often referred to as UI thread in LabVIEW.

You would have to query the window handle by class name rather than by window name. If you call

HWND hwnd = FindWindowA("LVFrame", NULL);

 from a Call Library Node, you should get back the handle to that hidden window. All other LabVIEW windows should be of class type "LVChild", but that doesn't mean that they are Windows child windows, simply that that are LabVIEW editor (user facing) windows.

However you do not need to intercept those messages to detect process shutdown. The LabVIEW Event Structure provides an actual Application Instance Close? filter event and an Application instance Close event. The first can be used to prevent LabVIEW from exiting but this needs to be used carefully. Until a few versions ago, once you prevented LabVIEW from exiting by passing a True to the Discard? terminal the only way to terminate LabVIEW after that was by killing it in the task manager. Every other attempt was blissfully ignored, including trying to call the LabVIEW Quit node.