External Dll Call

[omni]

Roger,

This will get your thinking cap going.

We have a third party dll we have been using for many years. (Rand McNally, Milemaker).

A normal call is something for miles is :
nMiles= DllCall( DLL_NAME, DLL_CDECL, "GetHHGDistance", cOrigin, cDestination)

Works great, has for years. We have many different calls.

They have one we have not used, but need to that is a call that returns two items, one is our 'equal', the other the route for the miles.

numlines= DllCall( DLL_NAME, DLL_CDECL, "Route", cLocations,,creturn,7,0 )

number of lines is our var, -0-, which has an answer every time. Great. (4=4 lines of 71 characters, for example)

The second is cReturn, which is our our space(5000)(empty buffer), its being returned, supposedly, but since there is no equal I cannot get it to 'refresh' to the updated value. It just stays as space(5000), or whatever I assign as the number of blank characters.
Do you think there is a way to make that a refreshable function of some sort. I think that has to be the problem. Their support team and tech personnel all say if there is a number of lines, there has to be something in the buffer. We have tested using C and Visual and it works right. (not our exe's, but ones they use)



Any thoughts are appreciated.

Fred
omni

[Wolfgang Ciriack]

Hi Fred,
have you tried the parameter per reference ( @creturn ) ?

[rdonnay]

Try this. You need to pass cReturn by reference.

Code: Select all

numlines := DllCall( DLL_NAME, DLL_CDECL, "Route", cLocations,,@creturn,7,0 )

[omni]

thanks,

worked like a charm.

Fred

[Tom]

Hi, Fred.

This is a very important concept in Xbase (an other languages aswell). If you transmit a function parameter "normally" (by value), just the value of the parameter is moved to the function. A local copy of this parameter is created by the function. Whatever the function does with this parameter, it has NO effect to the "origin".

Code: Select all

c1 := 'Test 2'
c2 := Whatever(c1)

FUNCTION Whatever(c) // senseless function 
c += 'x'
RETURN 'Test'

c2 equals 'Test' after the call of "Whatever", c1 stays the same. But if you do this:

Code: Select all

c2 := Whatever(@c1)

c2 equals 'Test' after "Whatever", but c1 changed from 'Test 2' to 'Test 2x'! A parameter given by reference can be manipulated by the function using this parameter! I often saw code like this:

Code: Select all

PUBLIC c1,c2,c3 ...

FUNCTION ... //
c1 := ...
c2 := ...
RETURN somethingcompletelydiffernt

People create PRIVATES or PUBLICS to have the possibility to change their values somewhere. This can be useful. But in most cases I saw, the programmers had no ideas about calling functions per reference. This is what most DLL-functions do, if they not only return a value, but change other parameters aswell. It's a very powerful and simple technique.

[rdonnay]

It hadn't occurred to me, until now, (thanks to Tom) that there are Xbase++ programmers who have such a long history with PRIVATE and PUBLIC variables, that they have never been introduced to the pass-by-reference operator - @.

Every language supports pass-by-reference because it is an important requirement for any kind of memory management and parameter passing.

If you are supporting legacy code, then there are probably no reasons to replace privates, but if you are writing new code, then either pass-by-reference, or object-oriented programming makes a lot of sense.

If you are interfacing with third-party DLLs, then pass-by-reference is the ONLY way to receive multiple parameters from the called function.

[unixkd]

If you are interested in pushing dynamic programming to its limit, using WINDOWS SDK platform and external DLLs, consider Yukon Project. visit www.knowleXbase.com