Passing variables instead of pointers works anyway ?

[newbie]

Hello,

That is just a simple curiosity I have.
For many API I have noticed that MSDN tells for a given parameter that it is a pointer to a variable/structure/memory address. However, sometimes when you pass directly the variable and not it's address, it works also.

Basic example :

Code: Select all

Module.s = "C:\Windows\system32\shell32.dll"

If LoadLibrary_(Module) <> #Null
	Debug "success"
	FreeLibrary_(Module)
Else
	Debug "error"
EndIf

From MSDN :

lpFileName
[in] Pointer to a null-terminated string that names the executable module (either a .dll or .exe file). The name specified is the file name of the module and is not related to the name stored in the library module itself, as specified by the LIBRARY keyword in the module-definition (.def) file.

If the string specifies a path but the file does not exist in the specified directory, the function fails. When specifying a path, be sure to use backslashes (\), not forward slashes (/).

If the string does not specify a path, the function uses a standard search strategy to find the file. See the Remarks for more information.

Why does it work, whereas it should be :

Code: Select all

LoadLibrary_(@Module)

Just wondering

Regards,
newbie.

[Trond]

When you pass a string to a procedure you actually pass the address of the string (another copy is not made before the call).

Then, inside the procedure, another copy is made if necessary.

@String returns the address of the string as a long. This is only strictly useful in PB only programs because the PB compiler performs type checking. So if you pass a String.s to a procedure that expects a pointer the compiler will error out as a convenience. To tell the compiler that you really meant to pass the pointer (you know that the procedure will not make another copy locally) you pass the address instead. However, the exact same thing is passed.

[newbie]

Thanks for the explanation, I didn't know the address was always passed for a string to an API. Things are clearer now