Select a Windows ListView item using windows messaging

[Viper]

I am trying to control another programs GUI with windows messaging. On of the GUI items is a List-View.

As shown item index 3 is currently selected. I need to select a different item and am trying to use this method show here.

Attached is my attempt but its not working. Am wondering if my CIN is setup correctly?

[mikeporter]

What exactly does "not working" mean? Errors? BSOD? 

Mike...

[rolfk]

This code has several problems really!

Some of them are outright wrong, others are at least potentially bad!

1) You can't put a LabVIEW string into a structure when the funciton expects a C string pointer. A LabVIEW string is NOT a C string pointer! Basta! If the parameter itself is the C string pointer you can configure the Call Library Node to convert the LabVIEW string into a C string pointer but there is no such option to tell the Call Library node to also convert the LabVIEW string inside the Cluster into a C string pointer. This is only potentially a problem since this message is not supposed to even care about the pszText element in the structure, so you may get away with a LabVIEW string handle instead of a proper C string pointer in there as they poth use a pointer sized value, but more correct would be a integer as described unter point 2).

2) You have forgotten to add the lParam element in the Cluster. This is a pointer and therefore should be an (u)int32 when used in 32 bit LabVIEW and an (u)int64 when used in 64 bit LabVIEW. there is no way to have LabVIEW automatically use a pointer sized integer inside a cluster, so if you ever intend to make the code compatible to both 32 bit and 64 bit LabVIEW you would have to use a conditional compile structure and create the two different clusters explicitedly. Again this potentially could be a problem but you might get away with it since there is no information in the cluster after this element that the message is supposed to care about, so it seems likely that it won't try to access any of the elements after the missing lParam.

3) A handle in Windows is a pointer sized variable. So you should configure the first parameter of the Call Library Node as such. Otherwise you limit this code again to only be executable in 32 Bit LabVIEW.

4) You configured the CLN to run in the UI thread. This is usually the safer of the two options but when dealing with Windows messages it is in fact more dangerous. It may work here since you are trying to send a message to another process but it would likely deadlock badly if the receiving end would be your LabVIEW process itself. The LabVIEW windows message handling is going through the so called root loop that is executing in the UI thread. The Windows SendMessage() function is synchronous (unlike PostMessage()) and will only return after the target message loop has retrieved the message and processed it. But if that target message loop is handled by LabVIEW it won't be able to do that since the UI thread in which it works is still blocked inside the call to SendMessage(). A classical deadlock situation occures! Since your target message loop is in a different process, this problem is not so likely to occur, but I alwaays try to avoid calling SendMessage() in the UI thread.

Since you call the VI SetItemState I would only put the state and mask items on the front panel and fill them into the cluster on the diagram. That makes it clearer which parameters are really relevant.

Last but not least where do you get the handle for the ListVIEW in the other program from? This will be generally a rather involved process with several Windows API calls to get at that handle and you show absolutely nothing in terms of how to get at that.