pointer to a 32 byte buffer

[Mathan]

Dear Champions,

In my application, everything is fine.

1) sCardEstablishContext works fine

2) sCardListReadersA showing correct name of my reader

3) sCardConnectA give proper mode(1) and protocol(1) values

4) sCardStatusA ???????????? There is the problem. It gives state(6 - reset) and protocol(1). That is correct i think. But ATRLEN is 0 and no ATR was received and most of the times labview crashes when the data comes to scardstatus(when i run in highlight execution).

I attached my vi and dll in zip format.

Please do the needful asap

Thanks,

Mathan

[rolfk]

---

@Mathan wrote:

Dear Champions,

In my application, everything is fine.

1) sCardEstablishContext works fine

2) sCardListReadersA showing correct name of my reader

3) sCardConnectA give proper mode(1) and protocol(1) values

4) sCardStatusA ???????????? There is the problem. It gives state(6 - reset) and protocol(1). That is correct i think. But ATRLEN is 0 and no ATR was received and most of the times labview crashes when the data comes to scardstatus(when i run in highlight execution).

---

And how did you configure the 3rd parameter? This is a string and a memory buffer too and if you do not allocate that memory in LabVIEW somehow you will have a crash.

As to the other parameter: atrLen is a pointer to an uInt32 and atr is a buffer with said length. In LabVIEW 8.5 you can configure an array parameter to be initilized automatically with the value of some other numeric parameter. That is what you have done initially and in that way the Initialize Array function would not really have be necessary but it won't hurt either and was necessary for any version prior to LabVIEW 8.5.

But check out your string buffer. You can not call a function that is going to return some information in a string without allocating enough space in the caller (here LabVIEW). Even if you configured the string parameter to be of the size passed by the 4th parameter you do not wire any number to that parameter so it will be 0 and the DLL likely was complaining about this parameter to be to short.

Rolf Kalbermatter


Message Edited by rolfk on 05-06-2008 08:42 AM

[rolfk]

---

@Mathan wrote:

---

You do need to enforce data flow dependency here. Calling the SCardFreeMemory and SCardReleaseContext functions in parallel is likely to deallocate resources that might still be needed in SCardStatus. So using data dependency you will want to make sure that those functions are called after all other Scard functions have finished executing.

And SCardListReaders has a string parameter that is initialized as an empty string. Luckily you also leave it's associated length parameter empty so this will be 0 and therefore the DLL function is likely to simply not insert any data and this will not crash but the fucntion call is in fact not doing much either.

Also this parameter is a so called multi string list parameter. This means it can contain multiple NULL terminated strings and is terminated with a double NULL. LabVIEWs call library Node will for string parameters only return the first string as it will stop on the first encountered NULL char. As long as you are fine with only connecting to the first reader that could be present in your system that is no problem but if you want to be able to connect to any one of multiple readers you would have to treat this parameter as an array of Bytes and then parse the resulting array yourself into an array of strings.

Rolf Kalbermatter

Message Edited by rolfk on 05-06-2008 09:03 AM

[Mathan]

Dear rolfk,

---

And how did you configure the 3rd parameter? This is a string and a memory buffer too and if you do not allocate that memory in LabVIEW somehow you will have a crash.

---

I configured that 3rd parameter as string (c string pointer) and minimum size dwReaderNameLen

As to the other parameter: atrLen is a pointer to an uInt32 and atr is a buffer with said length.

I did whatever you said. atrlen is a pointer to an uint32. But i initialized atr as an array data pointer with minimum size as atrlen - is it correct?

But check out your string buffer. You can not call a function that is going to return some information in a string without allocating enough space in the caller (here LabVIEW). Even if you configured the string parameter to be of the size passed by the 4th parameter you do not wire any number to that parameter so it will be 0 and the DLL likely was complaining about this parameter to be to short. 

---

So what value i have to give to the 4th parameter? i did like the attached one.

And what to give to ATRLen?

Thanks,

Mathan

[Mathan]

Dear rolfk,

if you want to be able to connect to any one of multiple readers you would have to treat this parameter as an array of Bytes and then parse the resulting array yourself into an array of strings.

How to achieve this?

Please give me some screenshots how to build this.

Thanks,

Mathan

[Mathan]

Dear rolfk,

---

using data dependency you will want to make sure that those functions are called after all other Scard functions have finished executing.

---

The attached vi is ok ? I have introduced error out to error in to all nodes in order. Will it be ok?

Thanks,

Mathan

[Mathan]

Hai,

I did with all the corrections. Now no crash occurs.

But still sCardStatus will give a return value of 80100008 which indicates

---

The data buffer for returned data is too small for the returned data

---

How to proceed?

Mathan

[Mathan]

Dear MIKES81, GerdW, smercurio, rolfk,

I was really to say that the problem got solved. What i did was, i just removed the 2nd and 3rd inputs i declared for sCardStatus dll. Everything is fine now and proper ATR is returning.

Thanks all of you for ur kind and continuous support,

Mathan

[Mathan]

Dear all,

And my next step is i have to create a log file.

Any suggestions how to implement it for my application?

Thanks,

Mathan