Information générale
Catégorie:
Fonctions Windows API
If he doesn't drop the @ from the call, then he needs it in the Declare, right?
Also, I don't remember seeing BYREF or BYVAL on any of the original VB parameters. Therefore, they're all probably using the default of BYREF. I wonder if he needs to pass all four parameters by reference?
>>Did you also try to remove the "@" from the actual call? According to the FoxPro help for the error message you listed, this error occurs during the call to the DLL, not the declaration.
>>
>
>The effect of dropping the @ from the actual call would mean that the data would not be propagaged back from the function call; the data value is unaffected by any changes made within the DLL, so that it couldn't be used to receive a result from the function.
>
>>>>>>
>>>>>>This makes no sense; why would you declare one of the arguments of type & as "long @" and the other "long"? The odds are that one of the two long declares is completely FUBAR, and either both should be declared LONG, or LONG @ (LONG is ByVal, LONG @ is ByRef)
>>>>>
>>>>>The tcpHandle needs to be modified by the called program, so I declared it as by reference. maxTime is a parameter that I would typically pass in as a constant.
>>>>>
>>>>
>>>>THe declaration is unaffected by the need to capture a changed value - you use @ in the function call to allow any change to propagate back; declaring it in the DECLARE...DLL has a definite and different effect; LONG passes a 4 byte integer, while long @ passes a pointer to what is presumed to be a 4 byte integer. See CLSHEAP to see examples of where to use each.
>>>
>>>Thanks for that info, i wasn't sure what @ would signify in the DECLARE statement.
>>>
>>>With that in mind, my DECLARE should be without the @. Nonetheless, I still have a problem elsewhere.
Précédent
Suivant
Répondre
Voir le fil de ce thread
Voir le fil de ce thread à partir de ce message seulement
Voir tous les messages de ce thread
Voir tous les messages de ce thread à partir de ce message seulement