Accessing DLL buffer data after receiving Windows Message

[Anil_Reddy]

Update.....Not sure what happened, but ActiveX started working.....when i tried last time, though i registered .OCX file, I was unable to browse the typa library of this. now I am fighting with Call back events.....I am successful in geting parameters data, Now I am working on decode data..........But I still like to make the DLL thing working..........

Thanks

[rolfk]

Ok a number of remarks.

First you configure the return value of DSNewPtr() as pointer sized unsigned integer (which is fine) but let the other functions where you pass this value to adapt to its size which will cause a coercion since it will see this as an unsigned 64 bit integer. Make them unsigned pointer sized integers too.

MoveBlock has no return value.

The return value of DSDisposePtr is a LabVIEW manager error. That is likely not a good idea to pass to Disconnect as hWnd. Same with the pointer you pass to that function as port number.

Maybe it is just because I do not have any hardware available but all the SSI functions except the Connect function return a -1 value indicating an error.You definitly should add some error handling by using the return values of the functions. Also DSNewPtr could theoretically fail, because of out of memory conditions and going on with a NULL pointer is likely causing a crash (eventhough it is not likely you get much further in out of memory conditions anyway).

In addition to actually having the right hardware available I assume one should also pass valid parameters to the Connect and Disconnect function. Baudrate and port seems quite obvious but the windows handle would be the handle of the window of which you have hooked the message queue. It may work without a handle and the according event handling that waits for the message but LabVIEW most likely will be way to fast in calling the MoveBlock function after you executed the RequestParameters function, so it will read the buffer before it is actually filled.

Message Edited by rolfk on 12-14-2009 11:34 PM

[Anil_Reddy]

Hi Rolf,

I did copy paste of some part of the code from my applications and sent that to you. Yeah, i have error handling in the application, so it is taken care. i followed your suggestion in the parameters data types declaration.

///....Also DSNewPtr could theoretically fail, because of out of memory conditions and going on with a NULL pointer is likely causing a crash (eventhough it is not likely you get much further in out of memory conditions anyway)....///

How to avoid this then?

Before calling move block I actually have another function which monitors windows messaging queue. Once that finds the message from Scanner as WM_Decode, it will come out and Move block function will execute.

After move block function, data I am getting in the destination array is the pointer value in the first byte, and nothing else.

Thanks 

Message Edited by Anil Reddy on 12-15-2009 07:36 AM

[Anil_Reddy]

 Hi,

 I could work with ActiveX control given by the vendor. I am able to catch the parameter request event and ge the requested parameter value from scanner. But I am unable to catch the Decode data available event. Not sure where it is going wrong.

Here I am attaching the VI. Could you please help me in this.

Thanks

Message Edited by Anil Reddy on 12-15-2009 09:22 AM

Message Edited by Anil Reddy on 12-15-2009 09:25 AM

[nathand]

I don't quite understand your event structure; why are you catching "length: value change"?  Length is an indicator and that case will never be triggered.

Try putting a messagebox in your callback VI, so you can find out if the callback is ever called.  If it is, then you just need to figure out why you're not getting data from the callback function to the rest of your program.

[Anil_Reddy]

I was interested in User event rather than that length: value change. So that can be ignored. I tried putting message box, and i get nothing. when i run the application. that means call back function is not getting called on the occurrence of the event.

[Anil_Reddy]

Hi,

Finally I got data from scanner.......I am excited.....

There is a parameter for Decode event only , I needed to enable that event reporting. This is specific to Decode event. They should have mentioned it in their document properly. Anywayz i could find that thing and Now I am Up and Running.............ooooooooooooooooooaaaaa

Thanks you Nathan and Rolf

[nathand]

---

Anil Reddy wrote: 

Before calling move block I actually have another function which monitors windows messaging queue. Once that finds the message from Scanner as WM_Decode, it will come out and Move block function will execute.

After move block function, data I am getting in the destination array is the pointer value in the first byte, and nothing else.

---

This is probably too late to be useful since you already have it working with ActiveX, but while responding to another post I realized why MoveBlock was not working properly for you, and you mentioned that you would still like to get the DLL solution working, so I'm adding this for the sake of completeness.  Rolf made this point in passing in an earlier post but I missed (or misunderstood) it, so I thought I'd clarify.

MoveBlock isn't working because the value from DSNewPtr is a pointer.  The value in your U32 is an actual address in memory.  When you pass that value to a function such as MoveBlock that expects a pointer, you need to pass your pointer by value.  Otherwise, LabVIEW will provide the address of your pointer, which isn't so useful - but explains the behavior you're seeing where the first byte of the destination array is the pointer value.

[GustavoRamirez]

Hi Anil,

It's glad to hear that you happened to make your scanner to work!

I ran in to the same when trying to get the data from a MS4407. But, there is a little difference, this has a USB interface, not Serial, hence I'm using the SNAPI dll from Symbol. And I have the same problem, I can init, connect, and retreive the Scanner S/N, but when try to get the data from the scanner I get nothing, I'm pretty sure is the same issue, because I have been trying to debug the sample code in C# that came with the scanner and it's the only thing I find different.

Could you post your final code, to see if it can be helpful to find the solution for me?

Thank you very much!

Gustavo 

[Anil_Reddy]

Hi Gustavo,

I could make it work using ActiveX Control provided by the manufacturer. I used ActiveX events to catch the data. I Tried with API calls also, but did not continue due to time constraints.

If you want to try to do with API calls, you are into some problems. First you have to catch windows messages, this can be done by using a DLL found in NI website.

But the issue is moving data from the buffer to LabVIEW. I tried to use MOveBlock logic.but somehow it started crashing the LabVIEW due to memory issues. later i did not get a chance to work using API as I already got it working with ActiveX Control. I am planning to work on that again after few days when i get some free time......

I am not sure whether motorola gave ActiveX Control for SNAPI also........

ALL THE BEST

Anil