Are you calling me?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

The error is occuring in a function, but the function is programmed properly.
The value sent to the function is wrong. So I want to know who is sending the
wrong value. Is there a way to identify from where the function is being
called. I could put breakpoints on all the events, but functions can be
called from other forms and modules, so that could get rediculous. Thanks
 
So I want to know who is sending the
wrong value. Is there a way to identify from where the function is being
called.
Click to expand...

Set a breakpoint or a Debug.Assert or a Watch and look at the call stack
(ctrl-L in the VBE).

Consensus round here seems to be that the call stack is not available
programmatically, and just as well as far as I can tell.

The other way is the oldfashioned way: test which user actions are causing
the error and follow the code...


Hope that helps


Tim F
 
In
Michael Conroy said:
The error is occuring in a function, but the function is programmed
properly. The value sent to the function is wrong. So I want to know
who is sending the wrong value. Is there a way to identify from where
the function is being called. I could put breakpoints on all the
events, but functions can be called from other forms and modules, so
that could get rediculous. Thanks
Click to expand...

Without changing the code, there's no easy way to tell what procedure
called it. You could, of course, change the function to receive an
extra argument, which would be the name of the caller. What you can do,
which may or may not help for your purposes, is interrogate
Screen.ActiveForm.Name within the function to find out the name of the
active form when the function is called. Does that help?
 
Thank you both for the suggestions. I suspect I have no Control-L because I
work only with VB with Access, not the full program, but thanks anyway Tim.
And I haven
't bothered to learn how to use the locals or watch windows. Anyway, Dirk,
you said it could not be done, so I took Tim's suggestion and put breakpoints
on the first line of every procedure, function and event on that form and
found the problem. The answer surprised me.

The form is for employees and has an up and down arrow to move up the list
of managers and back down to where you started. However, at the top, where
the employee and the manager are equal, I disable the up arrow. When you
click on the disabled up arrow again the form header executes a tab to tab
one, not the next tab in the list. Well this moves the focus to the manager's
field, which was calling the function with what I thought was a wrong
variable. I reorganized the tab list so the up and down arrows are one and
two and now when you click on the disabled up arrow, it tabs to the down
arrow and the manager's got focus never executes. Problem solved be using a
lot of breakpoints and following the bouncing ball. Thanks for your help.
Regards,
Michael
 
"Michael Conroy" wrote
I suspect I have no Control-L because I
work only with VB with Access, not the
full program, but thanks anyway Tim.
Click to expand...

What are you talking about? Do you have the idea that it would be better to
work with a Jet database from a VB program created with the separate VB
product? If so, you are dead wrong -- it would be different, but not
better. The object models of classic VB, VB.NET, and of Access are
different, but the core VBA language of both classic VB and Access is the
same VBA6.DLL. VB.NET is something quite different.

Unless you do almost no VBA at all, you'd be well-advised to learn the
things you mention not knowing.

You might even consider getting the free MZTOOLS, http://www.mztools.com,
and setting up standard structure for your procedures which stores the
procedure name in a variable, and including that variable on all procedure
calls. That way, you could stop within the called procedure, and always
determine "from whence you came". That's not as extensive as the call stack,
but useful if you don't want to learn/use the call stack.

Larry Linson
Microsoft Access MVP
 
You might even consider getting the free MZTOOLS,
http://www.mztools.com, and setting up standard structure for your
procedures which stores the procedure name in a variable, and
including that variable on all procedure calls. That way, you
could stop within the called procedure, and always determine "from
whence you came". That's not as extensive as the call stack, but
useful if you don't want to learn/use the call stack.
Click to expand...

You could easily implement a class module to replicate the call
stack, such that you were recording the order of execution. Dunno
how you'd clear out the results after code finishes executing,
though.
 
Back
Top