PLIN-API - Visual Basic 6 support?

[PeakPins]

Hello to everybody,
due to compatibility issues with our old test equipment, I should need to write a Visual Basic 6 application with PLIN-API support, in order to communicate with an electronic unit using PCAN-USB Pro FD: the electronic unit is slave, PCAN hardware is master and sends messages to it.
Starting from the PLIN-API Example for VB.Net provided with PCAN hardware (and successfully tested),
I tried to rewrite it for VB6, so I created a PLIN-API.bas module with all dll aliases, and rewrote the code of the original main application.
In this way, I'm able to see the hardware, initialize it and send messages, but I'm encountering problems when I try to receive messages from the slave: using the LIN_Read function, it seems that the function is only able to receive "Bus sleep" or "Bus Wake up" messages type, while ignores standard messages.
The hardware filter is set to 0xFFFFFFFF, in order to get all messages, so I think it should not be a matter of the hardware initialization.

I would please ask you if, perhaps, it is possible to find an implementation of PLIN-API for VB6 (perhaps in some older versions), or, in alternative, if you are available to give me a little help to find out what it was going wrong, if I further send you some pieces of code I wrote.

Thanks in advance for your support,
with best regards.

Daniel

[U.Wilhelm]

we are sorry - the PLIN-API was never designed to use with VB6. Maybe you need to write your own Wrapper (using PLIN API with a C++ Language and add a own Interface to VB6).
If you like we could take a look at your VB6 code - but could not guarantee if we are able to fix/find the problem. Please send to support[at]peak-system.com

[PeakPins]

Hi,
thanks for your reply.
I solved (or, at least, it seems).
The problem was in the LIN_SetClientFilter call: the original function in plinapi.dll accepts a 64bit data type for filter mask setting, but VB6 isn't able to manage such kind of data, I tried to pass a constant value set to &HFFFFFFFF, but this created the unpredicted behaviour I described in previous post.
So, I solved with this workaround:
- call the SetClientFilter passing "0" as filter mask (so I clean up all IDs)
- then call the RegisterFrameId passing 0 and 63 as First and Last ID

And its work!
Thanks anyway for your kind support and contribute.

With best regards,
Daniel

[U.Wilhelm]

thank you for the feedback !