Way to find name of running sub/function 2

[notuserfriendly]

Hi

I'm wondering if there's a way to
see what the debugger sees in the stacktrace
or if one can see the name of the running sub or
function when wanting to log to a file. Is there a way
?

 

[smandoli9]

See Thread

http://www.tek-tips.com/viewthread.cfm?qid=975155&page=1

Toward the end the Friendly Commenters concur there's not really a way, then proceed to wander from the topic into frinedly chat.

[purple]_______________________________
_{Never confuse movement with action -- E. Hemingway} [/purple]

 

[Remou]

Some of this may help:
Return name of procedure in which code is running
thread705-826614

 

[notuserfriendly]

I've actually been thinking of that, was wondering if there was an other easier alternative (takes a while to put it in all Subs and functions since they don't have the same name.

But then I'll do it this way.

/I

 

[macropod]

The other thing you'll have to watch for is subs that are called by others - you'll need to make sure to reset the strModuleName (or whatever you choose to call it) variable to the calling sub when the called sub finishes. This could be fun once you start getting calls nested a few levels deep. Either that or forgo logging the called subss names.

Cheers

 

[MichaelRed]

re the " ... lot of work to put it in all the subs ... ", there is somewhwere in these (Tek-Tips) fora, a rooutine to insert somc code into every procedure, which includes a debug routine. The procedure obtains the procedure names and inlcudes it in a text file used to trace execution on each call to each procedure. If you don't want to do the entire trace / dump. it could easily be adapted to the lesses purpose.



MichaelRed

 

[Remou]

Or modify the VBA Error Handler template?

http://msdn.microsoft.com/library/d...ore/html/derefode_help_errorhand_adderror.asp

 

[MichaelRed]

" ... modify the VBA Error Handler template ... "

Doesn't help post facto. Not many of us have the forsight to start out thinking of the necessity of modifying every item in a class / group in a particular manner. Others of us 'inherit' the relaticel large and ongoing application mostly as a result of this same lack of forsight in our predecessors.



MichaelRed

 

[notuserfriendly]

re the " ... lot of work to put it in all the subs ... ", there is somewhwere in these (Tek-Tips) fora, a rooutine to insert somc code into every procedure, which includes a debug routine. The procedure obtains the procedure names and inlcudes it in a text file used to trace execution on each call to each procedure. If you don't want to do the entire trace / dump. it could easily be adapted to the lesses purpose.

Looked for it but couldn't find it.
Found this one that says some more though

http://www.cpearson.com/excel/vbe.htm

 

[MichaelRed]

hmmmmmmmmmmmmmmm ... mmmmmmmmmmmmmmmmm

The referenced site includes enough sample code to see the generic process of modifying modules and procedures, so I won't go looking for the specifics unless requested.

A caveat (or two):

generally do NOT allow the procedure which modifies other procedures to attempt to modify itself.

when inserting lines of code into a module / procedure, make sure that you recheck the line number / counter frequently. Inserting a line of code (obviously?) changes the identification (line number) of all lines following, so either start from the "bottom" and work your way to the top, of check where you are inserting / deleting quite frequently.



MichaelRed

 

[smandoli9]

MichaelRed may be thinking of Thread 975155.

I started that thread, but balked at implementing. I felt the return in trouble-shooting would not be great enough to justify the work.

[purple]_______________________________
_{Never confuse movement with action -- E. Hemingway} [/purple]

 

[MichaelRed]

thread222-23282
thread707-740933
thread705-478726

represent a very few of the samples I WAS thinking about ...

MichaelRed