DLL Crash using 3rd party application

[gvogel]

Bingo! I wired the Window ref no. to the DLL and got the hWnd, Iparam , Wparam from the message queue. For some reason I was wiring the message queue ref no. to that input. Thanks!! Next step is to use the Iparam as a pointer to the COPYDATASTRUCT to finally extract the reply from the controller. Iv'e seen a post about using a CopyMemory function in a CIN block, and one about using the Access Hardware vi's available from NI to do a memory access. Didn't see much detail on either.

[rolfk]

---

@gvogel wrote:

Bingo! I wired the Window ref no. to the DLL and got the hWnd, Iparam , Wparam from the message queue. For some reason I was wiring the message queue ref no. to that input. Thanks!! Next step is to use the Iparam as a pointer to the COPYDATASTRUCT to finally extract the reply from the controller. Iv'e seen a post about using a CopyMemory function in a CIN block, and one about using the Access Hardware vi's available from NI to do a memory access. Didn't see much detail on either.

---

Use CopyMemory or MoveBlock (searching for MoveBlock here should give you some posts with explanation that would even allow you to not use a CIN but stay entirely in LabVIEW).
Access  Hardware absolutely won't work. These are to access IO Port adresses and physical memory, and that is something completely different from heap or stack memory access.

Rolf Kalbermatter

[Geovo]

I'm at the end of the line and I still can't get the response out of the controller. I take the lParam from the WM_Copy message which is a pointer to the COPYDATASTRUCT and pass it to the MoveBlock library function as a value to be used for the source pointer. I set up a LabVIEW bundle structure to receive the parameters of the COPYDATASTRUCT. For just making the connection with the controller I should get a "101"  for connected or "102" for not connected. The other parameters would be used in more complex messages that would pass data. I'm getting 7FD50038 hex which I can not construe as 101 whether you consider hex to ASCII or big endian vs little endian. I've tried a dozen differen things but nothing is working. I'm sure it's a simple thing again, but I'm just not seeing it. Attached is a view of the diagram.

[Dynamik]

Hi Gvogel,

      Any chance that the order of the controls in CopyDataStruct isn't dwData(0), cbData(1), lpData(2)?  When you say "I should get a 101", do you mean in either dwData, or cbData  - or are you de-referencing lpData in an unshown step?

Message Edited by Dynamik on 02-26-2006 01:36 AM

[rolfk]

---

@Geovo wrote:

I'm at the end of the line and I still can't get the response out of the controller. I take the lParam from the WM_Copy message which is a pointer to the COPYDATASTRUCT and pass it to the MoveBlock library function as a value to be used for the source pointer. I set up a LabVIEW bundle structure to receive the parameters of the COPYDATASTRUCT. For just making the connection with the controller I should get a "101"  for connected or "102" for not connected. The other parameters would be used in more complex messages that would pass data. I'm getting 7FD50038 hex which I can not construe as 101 whether you consider hex to ASCII or big endian vs little endian. I've tried a dozen differen things but nothing is working. I'm sure it's a simple thing again, but I'm just not seeing it. Attached is a view of the diagram.

---

First thing, make the len value 12 instead of 4. With 4 you are only copying the first element into the cluster. Then as Dynamik has said, where do you want to see "101"? If it is in the lpData element inside the cluster you will have to do one more pointer dereferencing with MoveBlock.

Rolf Kalbermatter