Call DLL from VB.NET – Return Values

Topic

New Reply

G’Day,
Got a bit of a weird one here. We have a DLL that we need to use to access a government claiming facility. I can link to the DLL with no problems and call functions from that DLL using either the old Declare statement or the newer .NET .

Anyway, my problem is that all functions SHOULD return a Long value which is’ 0′ if successful or a 4 digit error code if there was an error. No matter what I do, all return values from these functions are about 17 digits long, even if the function call was successful! I suspect this is some kind of handle address or ID for the function. I have tried using the whole IntPtr, assign some memory and use the Marshal.WriteInt64 function to get the return code but I still get the same handle ID. Any ideas on this one?

As an Example

The following code gets the version of the DLL module being used. It has one input, one output and a return value.

Function declaration:

Code:

Public Declare Function getVersionId Lib "c:easyclaimeasyclaimc.dll" (ByVal OutputBuffer As String, ByVal BufferSize As Long) As Long

OutputBuffer: Is a pointer to a NULL terminated string that returns the version of the DLL being used
BufferSize: The size of the buffer that will store the NULL terminated string
Return: A Long which is either 0 for success or a 4 digit error code

Function Call:

Code:

Dim lngReturn as Long
Dim lngBuffer as Long = 50



lngReturn = getVersionID(strOutput, lngBuffer)

messagebox.show(lngReturn.ToString)

The output (messagebox) is something like: 17632472837652480

Can anybody help with this one? We (obviously) don’t have access to the DLL source code and the support desk don’t provide language specific support (although their examples in the API show exactly what I’ve just demonstrated for VB).

Cheers
Toncc

Reply | Quote

Replies

OK, after days of stuffing around with this I have moved to C# and surprise surprise – that exact same code works a treat (well, modified for C#, obviously)! I’ve avoided C# for years as I was trained in VB and never had the need to move. But now I have, I love C#. It just seems so much more powerful.

One thing I have found though, my eyes are more tired after looking at C# all day as opposed to VB.

Anyway, for anybody else having this issue the resolution is – Move to C# or some other language the correctly handles pointers and reference values.

Ciao

Reply | Quote

Hi toncc,

I don’t know if this is a factor or not, but did you remember that a Long in the .Net implementations of VB is Int64 and not Int32? As a long time VB programmer who still has some old legacy VB6 apps to support I sometimes forget that myself. A VB6 Long is the same as a VB.Net Integer and a VB6 Integer is the same as a VB.Net Short. If your DLL is expecting an Int32 and you’re giving it an Int64… well, I’m sure you see what I mean.

It’s true that VB has its eccentricities, many of which were inherited from VB6 and earlier. And it’s also true that C# doesn’t carry that same kind of legacy baggage. But I wouldn’t abandon VB just because of that. First, consider who you’re working for. If your employer primarily uses VB (as mine does), then it probably wouldn’t be wise to try to push C# on them. Don’t get me wrong – I think any programmer in the Microsoft environment should learn C# at least enough to be comfortable with it. A lot of example and tutorial code is only available in C# and unless you can at least follow the syntax you’d be missing out on a lot.

For myself, I’m comfortable with C# but prefer VB. I find it easier to read and maintain in spite of its eccentricities. As for capability and performance, there is very little C# can do that VB cannot do just as well.

Reply | Quote

G’Day,
I had rememebred that! Though mostly becuase the API I’m using had it spelled out for us (it’s been a while since I learnt .NET at Uni…). The DLL is actually written in Java but you are still correct is saying that the Java long is a .NET integer. Even in C# I’ve had to use int wherever they have Long but that’s a no brainer. It didn’t matter what I tried in VB.NET though, I never got the correct return code just an ID/address of some sort.

We use Access and hence VBA here which many people look down on but we have built up quite a large, complicated database that does what we want and supports upwards of 20 concurrent users accessing a mixed SQL/Access back end (anybody that tells you Access won’t support more than about 5 concurrent users is wrong, we’re proof of that!). This is the first time we’ve had to use something other than VBA to do what we need and so long as it works, I’m free to choose whatever language I want to get the job done.

I do prefer VB as I’m not a full-time programmer and I too find it easier to read and pickup after months (years?) of not using it but I enjoy a challenge and as you said, knowing C# really is a good idea.

Thanks!
toncc

Reply | Quote