introspection capabilities

introspection capabilities

am 06.12.2007 21:55:25 von mirandacascade

Not sure if 'introspection' is the correct term, so apologies if
subject line is off-base.

1) Is there any functionality that answers the question: what module
am I in?
2) Is there any functionality that answers the question: what function/
subroutine am I in?

Suppose, for example, I wanted to write information to a log...each
entry in the log is along the lines of:

Program entered function abc in module mod1
Program entered subroutine def in module mod1
Program entered function xyz in module mod2
..
..
..

I realize that the programmer can add variables at the beginning of
each module or function or subroutine that answers those questions,
and one could obtain the log information in that manner. If, however,
there is a way to interrogate something in the system to get those
answers, that might a slightly safer way to get reliable results in
the log. What I'm thinking is that to the extent that one might copy/
paste lines of code (including the code that handles logging) from one
function/sub to another, then it would be more reliable to have the
system tell the application what the module/function is rather than
relying on the due dilligence of the programmer to create it or update
it after he/she copies the lines of code from somewhere else.

Thank you.

Re: introspection capabilities

am 06.12.2007 22:15:19 von Fester Bestertester

mirandacascade@yahoo.com wrote:
> Not sure if 'introspection' is the correct term, so apologies if
> subject line is off-base.
>
> 1) Is there any functionality that answers the question: what module
> am I in?

Application.CurrentObjectName

> 2) Is there any functionality that answers the question: what function/
> subroutine am I in?

AFAIK, Access/VBA doesn't have a delivered method or procedure for this.

Re: introspection capabilities

am 07.12.2007 03:48:44 von Allen Browne

It would be really useful in VBA did provide a way to read the
module/procedure stack, but AFAIK it does not do so.

For the module of a form, you can use Me.Module.Name, but it fails when you
convert to MDE.

CurrentObjectName may not give what you want. For example, if WhatAmI() is
in Module1, and you call it in the Click event of a command button on Form1,
it reports Form1 instead of Module1.

Function WhatAmI()
Debug.Print Application.CurrentObjectName
End Function

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Fester Bestertester" wrote in message
news:fj9opm$r4c$1@gondor.sdsu.edu...
> mirandacascade@yahoo.com wrote:
>> Not sure if 'introspection' is the correct term, so apologies if
>> subject line is off-base.
>>
>> 1) Is there any functionality that answers the question: what module
>> am I in?
>
> Application.CurrentObjectName
>
>> 2) Is there any functionality that answers the question: what function/
>> subroutine am I in?
>
> AFAIK, Access/VBA doesn't have a delivered method or procedure for this.

Re: introspection capabilities

am 07.12.2007 04:48:21 von Tom van Stiphout

On Thu, 6 Dec 2007 12:55:25 -0800 (PST), mirandacascade@yahoo.com
wrote:

For years in our company we are outfitting every procedure with a Push
and Pop function, which pushes the name of the procedure on a stack.
Then in the error handler we can report the stack trace. It's also
very useful for tracing.
We then developed some code that can automatically add these calls
after the fact, for example if we receive a home-grown application
without such facility.
That's really all you can do, unless you want to move up to .Net
programming.

-Tom.


>Not sure if 'introspection' is the correct term, so apologies if
>subject line is off-base.
>
>1) Is there any functionality that answers the question: what module
>am I in?
>2) Is there any functionality that answers the question: what function/
>subroutine am I in?
>
>Suppose, for example, I wanted to write information to a log...each
>entry in the log is along the lines of:
>
>Program entered function abc in module mod1
>Program entered subroutine def in module mod1
>Program entered function xyz in module mod2
>.
>.
>.
>
>I realize that the programmer can add variables at the beginning of
>each module or function or subroutine that answers those questions,
>and one could obtain the log information in that manner. If, however,
>there is a way to interrogate something in the system to get those
>answers, that might a slightly safer way to get reliable results in
>the log. What I'm thinking is that to the extent that one might copy/
>paste lines of code (including the code that handles logging) from one
>function/sub to another, then it would be more reliable to have the
>system tell the application what the module/function is rather than
>relying on the due dilligence of the programmer to create it or update
>it after he/she copies the lines of code from somewhere else.
>
>Thank you.

Re: introspection capabilities

am 07.12.2007 09:19:31 von Larry Linson

There are software tools that can add this information to your source
code -- a commercial product: FMS, Inc.'s Code Tools,
http://www.fmsinc.com/Products/access.asp (you can download a free trial),
and a free (though donations are accepted) product, MZTools,
http://www.mztools.com.

I have used both to include the information as text within error-handling
procedures. In my experience, Access is not sufficiently code-intensive to
need as much debug and trace information as some other development tools, so
I have never used a stack as you describe with Access (though I used that
technique on occasion in my previous incarnations as a mainframer and
minicomputer developer). Access is a great tool for pointing and clicking
your way to a friendly user interface, then adding just enough code to make
it work smoothly in a single-user mode, in multi-user mode, or as a client
application to server databases in a LAN or WAN environment.

Others have covered the options for obtaining the information at run-time
(which are limited, at best) and you've indicated you didn't want to code
the information as constants -- this automates coding the information, but
still leaves some vulnerability (though I have never had a problem doing it
this way).

Larry Linson
Microsoft Access MVP

wrote in message
news:47bff2ad-4f8c-4b77-a509-cbabbf11b34e@t1g2000pra.googleg roups.com...
> Not sure if 'introspection' is the correct term, so apologies if
> subject line is off-base.
>
> 1) Is there any functionality that answers the question: what module
> am I in?
> 2) Is there any functionality that answers the question: what function/
> subroutine am I in?
>
> Suppose, for example, I wanted to write information to a log...each
> entry in the log is along the lines of:
>
> Program entered function abc in module mod1
> Program entered subroutine def in module mod1
> Program entered function xyz in module mod2
> .
> .
> .
>
> I realize that the programmer can add variables at the beginning of
> each module or function or subroutine that answers those questions,
> and one could obtain the log information in that manner. If, however,
> there is a way to interrogate something in the system to get those
> answers, that might a slightly safer way to get reliable results in
> the log. What I'm thinking is that to the extent that one might copy/
> paste lines of code (including the code that handles logging) from one
> function/sub to another, then it would be more reliable to have the
> system tell the application what the module/function is rather than
> relying on the due dilligence of the programmer to create it or update
> it after he/she copies the lines of code from somewhere else.
>
> Thank you.