Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Passing Arrays from VB to VFP

Status
Not open for further replies.
Oct 21, 2002
22
US
Hi. I have written a small program in VFP 7.o and comiled it into a DLL. The main method in this DLL requires several parameters...

Some as type string (search criteria)
Some as long (number of records to return) and
Some as array (results from table searches)

This DLL works wonderfully from a front end written in VFP. However, when I try to call it from a Visual Basic front end I don't get the results I would expect. The parameters are passed successfully to the dll and the method executes correctly. I can verify this by looking at the temporary tables used to produce the results. The data contained in the variables in the VB program are not changed. It is as if they were passed by value, rather than by reference.

I am not a VB programmer by any stretch of the imagination and I am wondering if I am doing something wrong. Or maybe I have missed something in the VFP DLL? Can anyone help me with this?

Thanks,
Gwen
 
Gwen,
COM DLLs don't support initially "passed" parameters. (i.e. The object can't have parameters in the INIT() method.) Normally, you simply set the appropriate properties once the object has been created. Or you can call a method and pass it the parameters.

Rick
 
Thanks for responding. I don't think that I am being too clear here though. This DLL has 5 methods in it that the calling program can access. Some methods have no parameter. They simply return some value. For instance, to return the version number of the dll to the VB front end you do this...

cGCVersion = cGeo.GCVersion()

This works fine and the expected results are stored in the variable cGCVersion.

One method requires a numeric parameter passed to it. In VB this parameter is a LONG and is called like this....

For i = 2 To nAttribCnt
aFlds(i, 1) = cGeo.GetAttribFlds(i)
aFlds(i, 2) = ""
Next i

Here the method GetAttribFlds is returning the field name of a table. It is stored in an array in VB. This too works fine.

Now I get to the one that is driving me crazy. This method does some geocoding of an address and then returns a normalized address in the first four variables, the number of close matches (if no exact match is found) in the nRC field, the matchcode for the best matching address is stored in nMC, the array aBestMatches stores the addresses of close matches and the array aFlds is to store the geo/demographic data associated with the best matched address.

All variables are declared as PUBLIC.
cAdd1, cCity, cState, cZip are all of type STRING
nRC and nMC are of type LONG
aBestMatches and aFlds are of type STRING (I have tried VARIANT too.)

Calling the method from VB is done like this…

cGeo.geo cAdd1, cCity, cState, cZip, nRC, nMC, aBestMatches(), aFlds()

The program executes fine. There are no errors. The data contained in the variables used with the geo method are not changed. :-(

In an effort to determine what is going on I modified my DLL to write any temp files (cursors) to disk. I also wrote the memory variables to disk by issuing SAVE TO near the exit point in the method. I am certain that the variables are being passed to the method, the method is doing what it should and the values are correct. The values in the variable are not making it back to the VB front end.

I hope this makes it clear what I am encountering and that someone can make sense of this for me.

Thanks.

Gwen



 
Gwen,
While I'm still a bit confused, I believe that the answer comes down to the fact that VFP COM DLL's currently can't return an array that VB recognizes. The good news is that this appears to have been fixed in VFP 8.0! One of my programmers had a similar problem, and after trying the "bad" code in the 8.0 Beta, it worked fine!
While you can use:
DIMENSION myarray[5] as Long
DIMENSION mystrings[10] as String
in VFP 7.0, it didn't actually work - it now seems to in VFP 8.0.

Rick
 
Rick, that is what I thought as well. That is until I did this in my DLL...

FUNCTION Geo(caddr as string, cSity as string, cState as string, cZip as string, nRC as Long, nMC as Long, aFlds as Array, aBestMatches as Array) as Array
some code here
some more code here
even yet some more code here
endif
endif
endif
RETURN(aFlds)
ENDFUNC

and then call the method from VB like this

aFlds = call oGeo(cAddr, cCity, cState, cZip, nRC, nMC, aFlds, aBestMatches)

When I check the array aFlds in VB after calling it like this, WoW, it's filled with the correct data!

So this proves that arrays can be transferred from the VFP DLL to the VB front end. It does not get me any closer to why the entire parameter list won't be transferred though. :-(

Gwen
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top