I've been looking for this answer for years just to satisfy my curiosity and haven't found it. Now I need it.

I want to provide the name of a sub or function procedure in my forms and classes to my error handler.

The easiest approach is to set a variable to a string value at the beginning of each procedure and pass the variable to the error handler.

The minor downsides of this approach are that you have to remember to change that variable if you change the name of the procedure or if you copy and paste code from one procedure to another.

The major downside of this approach right now is that I am working for a client who has some strict coding rules that they enforce. One of which is to not hardcode any strings in procedures.

Now I guess I could make a bunch of constant strings with the values for these procedure names, but I really think there out to be a more elegant and efficient way to do it. I just can't come up with any ideas.

So if the experts could provide instruction or point me to a place where I could see some examples, I would really, really, appreciate it.

When a program is compiled, variable names, constant names and function names are tokenized, and eventually turned into addresses or offsets. (Constant references are replaced with the literal values of the constants, still making it so that the name of the constant is gone from the code.)

There simply is no way to do what you are asking.

I would try to explain to the client what it is that you are trying to do, and explain the simplicity and utility of just setting a string variable, as you described. Explain that it does not actually affect the program, only the error reporting contents.

Alternately, perhaps you could hard-code an argument to the error procedure...

(Clients! Life would be so much easier without users!)

Actually: how can I make money without users :(

It is indeed possible to get the current module name using the StackWalk API (that is used in the debugger to show the call stack), but it is not really something I would try in VB. The clients are always right, but that does not mean we cannot talk with them

Marco

I think they should just “trust us! It works perfectly! (Hey! Don’t touch!)”

Doesn't that ability work in a compiled program only if the debugging option is enabled in the project properties (Create Symbolic [u]D</u>ebug Info)?