david_Barkley
01-09-2002, 09:26 AM
How do you run one subroutine from another.
I have a field with the condition when exit. Inside this subroutine, I want it to run my command button subroutine.
Is there any to do this. I thought about gosub, but the way it looks, gosub only moves you around inside the active subroutine.
Pat Hartman
01-09-2002, 12:44 PM
I would use the Call statement since your procedure is in the current database. If your procedure is a Subroutine you can use either of the following statements:
1. Call YourSub(arg1,arg2,...)
2. YourSub arg1, arg2, ...
Notice that if you use the Call keyword, you must enclose any arguments in parentheses. If you omit the Call keyword, you must NOT use parentheses to enclose any arguments.
If your procedure is a Function that you want to call as a Subroutine rather than use as a function then:
1. Call YourFunc(arg1,arg2,...)
david_Barkley
01-09-2002, 12:51 PM
I ended up using the call statement and it is working great.
Thanks for all of your help.
Fornatian
01-10-2002, 07:51 AM
Does using the Call statement make any difference really?
david_Barkley
01-10-2002, 07:57 AM
I just tried it without the call, just the sub name and args and it worked fine.
So, the call is not needed.
Fornatian
01-10-2002, 11:43 AM
I wanted to know if made ANY real difference to code performance - PAT? Does the Call function do something that sub reference on it's own does not? If not why does it exist?
Pat Hartman
01-11-2002, 02:36 PM
I like to use the "Call" structure because it's a visual clue that the program is executing something I wrote rather than some internal VBA command. The other advantage is that it does not matter if the procedure you are caling is a Sub or a Function. You cannot execute a Function using the other syntax.
I doubt that there would be a measurable difference in the execution speed of the two reference styles.
As to why the Call syntax exists - I'm sure it is because it is the structure that basic used. The Call statement exists in every language I have ever worked with and is more or less universally understood. The second reference style was probably some programmer's idea of a shortcut because he didn't want to type the extra characters. What I can't rationalize is why the arguments would be enclosed in parentheses in one case but not in the other. I think just to cause syntax errors http://www.access-programmers.co.uk/ubb/smile.gif
There was a book written in the early 70's by an old friend of mine that even today makes for interesting reading. It was called "The Psychology of Computer Programming" and written by Gerald Weinburg (who is still writing interesting books today). One of the points that Gerry made in this book was that the most important measure of a "good" programming language was consistancy of syntax and a single way of accomplishing any task. By that measure VBA fails miserably and C is worse. The point he was making was that multiple commands that do the same thing cause an unnecessary strain on the mental energy required to program successfully. If I use the Call syntax because that is what I am familiar with and you use the other syntax because that is what you learned first, we each experience at least a small hiccup reading code written by the other even though we both know the language well. The fact that we're even having this discussion at all is non-productive (not that I don't enjoy offering opions). Anyway, there's no need to rush out to buy the book, if your library stocks technical references you can probably find it there.
Fornatian
01-11-2002, 10:59 PM
I think your friend was right, we've both expended far too much time(which we have increasingly little off) and energy(which we lose through kinetic loss in typing and brainwave heat). Alternatively, in economics there's an expression called 'opportunity cost' - the cost of one choice over the other. It's reference here is that the cost/benefit of using Call or not makes no difference so we both lose out if we each consider if we should be using one over the other.
So it's agreed then, business as usual.