GetProcAddress Replacement

[Cliff Nichols]

I know I can use GetProcAddress to get a pointer to a function in a dll, and I can use CodePtr to get the address to a function in my exe. But I have a unique situation that I can not solve.

1. GetProcAddress - Although uses a string for a function, only seems to work with a dll?
2. CodePtr - Although works for Functions in my Exe, does not allow for a string to be used for the name of the function?
3. CallByName - Although seen in VB, and found in Jose Roca's forum, comparing the 2 I realize only works on COM objects

What I am trying to do (and maybe can't be done) is be able to use a string like "CallByName" to call my function at runtime, that is not known at compile time.

I have tried comparing pointers to match the function as a string to the function itself, but not being the same, the pointers are not the same.

Googling things I see hints of the PE for a file (compiled as DLL or as EXE) are the same, so I hope that is the answer, but overall, has anyone done something like this???? or know how to do it?? or something I have not thought of yet???

[Scott Slater]

You could EXPORT the functions in the EXE, and then similarly call the functions like a DLL call.

[Chris Holbrook]

...or make a global table in the main program containing the function name and CodePtr for each such function.

[Michael Mattias]

What I am trying to do (and maybe can't be done) is be able to use a string like "CallByName" to call my function at runtime, that is not known at compile time.

I do that in several products; the "name" is stored in a configuration file.

The only way is GetProcAddress(), which WILL get an address of any EXPORTed function in the "module of interest." (and WON'T find any non-exported procedure)

However, there is NO way to get the "procedure header" describing the number and data types of parameters.

MCM

[Cliff Nichols]

Below is an example of the problem I am having. Although the function is exported, I can not find the function via GetProcAddress

#COMPILE EXE
#DIM ALL
#INCLUDE "Win32Api.inc"
DECLARE FUNCTION StartTracePort ALIAS "StartTracePort"() AS LONG

FUNCTION PBMAIN () AS LONG
LOCAL ModuleHandle AS LONG
LOCAL FunctionAddress AS LONG
ModuleHandle = GetModuleHandle("CallFunction.exe")
'ModuleHandle = LoadLibrary("CallFunction.exe")
'FunctionAddress = GetProcAddress(hInst, BYCOPY ucase$(FunctionToCall))
FunctionAddress = GetProcAddress(ModuleHandle, BYCOPY UCASE$("StartTracePort"))
MSGBOX STR$(ModuleHandle) + $CR + STR$(FunctionAddress)
END FUNCTION

FUNCTION StartTracePort ALIAS "StartTracePort"() EXPORT AS LONG
     MSGBOX FUNCNAME$
END FUNCTION

I have to wonder if its because the exported function is within this exe itself? or if thats the case, wouldn't that also be true if it were in a dll that is mapped into my program's memory space?????

Either that or I am doing something wrong

[Michael Mattias]

Give me a , please:

FunctionAddress = GetProcAddress(ModuleHandle, BYCOPY [B][COLOR="Red"]UCASE$[/COLOR][/B]("StartTracePort"))
...
FUNCTION StartTracePort[B][COLOR="Red"] ALIAS "StartTracePort"[/COLOR][/B]

MCM

[Cliff Nichols]

Ok that fixed my example, but not my real code. Now I have to find another way to demo my problem, or find the problem in my much larger code

Thanks MCM, I should have seen the doh syndrome before, but I have been staring at this farrrrr too long.

[Cliff Nichols]

Add on another point (I am really racking up the points today)

[Michael Mattias]

Yes, you earned that , BUT.... you also get , as the late Rodney Dangerfield would have said, "One-A-Dese" ===> :arco:

Why?

Because you - unlike several of your colleagues - DID post sufficient code to diagnose the problem.

MCM