>>Help! I'm having difficulty with the proper way to pass a variable to a VB dll subroutine that changes the variable: Here's my code:
>>
>>Public RetVal
>>RetVal = 0
>>LOGS = createobject("LogServer.ActivityLogServer")
>>LOGS.Log("Root",101,14,RetVal)
>>
>>... The dll subroutine "Log" works perfectly receiving the first 3 parameters. The problem is that "RetVal" is not getting set by Log (RetVal always stays at 0). I've also tried:
>>
>>LOGS.Log("Root",101,14,@RetVal)
>>
>>In the VB declaration, "RevVal" is declared as Variant. A VB test application proves that RetVal, is getting set correctly.
>>
>>What do I need to do so RetVal picks up the change made by the dll?
>
>A "variant" is basically a "structure". You'll have to pass a string (probably 16+ bytes) by reference and parse the result. The "type" would be in the first byte (I think), and the "data" in the 5th+ bytes. If the variant is a "string", it would be a pointer to a string.

Gerry -- I don't think that's correct, unless I am misreading his post. A variant is a pretty vanilla VB data type -- the VB equivalent of a struct is a user-defined-type.

In fact, a VB variant is pretty similar to every VFP variable -- it is a data holder of indeterminate type. Not hard-typed like "string" or "integer."

The value/reference confusion may stem from the different ways in which VFP and VB handle passing by val/ref. In VFP, we basically decide how to *pass* an argument, while in VB, we basically decide how to *accept* a parameter. So, in VFP we can pass to a function by ref with "@" or by value with parenthesis, or by SET UDFPARM TO VALUE/REFERENCE. But in VB it's determined in the parameter list. So, my guess, based on what he offered in the post, is that he simply needs to change specify "ByRef RevVal as Variant" in the argument list.