Call function by name as a string

[Jonathan Scott via AccessMonster.com]

Is it possible to call a function/sub by name as a string. I want to be able
to pass the name of a public function to another subroutine, who will then
call that arbitrary function for me. Is this possible in Access97?

Jonathan Scott

 

[Dirk Goldgar]

Is it possible to call a function/sub by name as a string. I want to
be able to pass the name of a public function to another subroutine,
who will then call that arbitrary function for me. Is this possible
in Access97?

You can use the Eval function, as in

Eval "YourFunctionName()"

or, if you want the return value,

varRet = Eval("YourFunctionName()")

Any arguments for the function have to be built into the string you pass
to Eval.

Or you can use the Run method of the Application object, as in

Application.Run "YourFunctionName"

You can pass arguments to the function via that method, too. See the
help file for details.

 

[Jonathan Scott via AccessMonster.com]

Thanks for the help, Dirk! This got me going. However, one problem I am
having is that I am not able to trap errors in that function/sub where I am
calling Application.Run. Any suggestions on getting the error to make it all
the way to Application.Run?

Jonathan Scott

 

[Dirk Goldgar]

Thanks for the help, Dirk! This got me going. However, one problem I
am having is that I am not able to trap errors in that function/sub
where I am calling Application.Run. Any suggestions on getting the
error to make it all the way to Application.Run?

Hmm. I'm not sure you can, but I've only just now tried it in a cursory
fashion. I suppose at worst you could use a Function instead of a Sub,
and have the function's return value be the value of Err.Number and/or
Err.Description. Then you could use Eval instead of Run to execute the
function, and examine the return value.

 

[Dirk Goldgar]

Hmm. I'm not sure you can, but I've only just now tried it in a
cursory fashion. I suppose at worst you could use a Function instead
of a Sub, and have the function's return value be the value of
Err.Number and/or Err.Description. Then you could use Eval instead
of Run to execute the function, and examine the return value.

Alternatively, you could use Run, but write the Sub to store its error
information in global variables, or controls on a form, or even a table.

 

[Jonathan Scott via AccessMonster.com]

Thanks again, Dirk. Evel() would be very nice, but it appears that the
function has to be within the same module/class. I really wish we had
upgraded to a newer Office version, already. (>_<)

I think I'll just write to global variables. Thanks again,
Jonathan Scott

[quoted text clipped - 6 lines]

Err.Number and/or Err.Description. Then you could use Eval instead
of Run to execute the function, and examine the return value.

Alternatively, you could use Run, but write the Sub to store its error
information in global variables, or controls on a form, or even a table.

 

[Dirk Goldgar]

Thanks again, Dirk. Evel() would be very nice, but it appears that the
function has to be within the same module/class.

Huh? No, it doesn't. What makes you think that? But in either case,
Eval() or Run, the procedure name has to be global in scope -- i.e.,
defined in a standard module -- or else, if it's defined in a class
module you have to include a reference to an instance of the class in
the string you pass to Eval().

Also, remember when calling Eval that you have to include the
parentheses after the name of your function in the string you pass to
Eval. Like this:

Eval "MyFunction()"

or

Eval strFunctionName & "()"

 

[Jonathan Scott via AccessMonster.com]

I just tried your way again, and realized, if Eval() is going to return a
value, it must be calling a function! Doh! So I changed what it is calling to
a function, and it worked. Thanks for the help!

Now, if only I can find a way to simulate a click on a form control
programmatically!
Thanks again!
Jonathan Scott