Over the years especially with most things but in particular with MS Access I noticed that people just take things for granted. Somebody says you shouldn't use global variables. Actually you can use global variables, is just that there are much safer ways to do it. What I'm trying to say is people accept the status Quo the accepted methodology without question. I like to think that I don't. I will ask annoying questions of my peers and betters until I get to the truth.
I remember years ago a farmer bought a brand new tractor for his farm. One of the conditions of using the tractor for the Warranty was to use a specific oil from British Petroleum, a very expensive oil, 3 times more expensive than the normal Farm oil in use. The Warranty said if you didn't use this oil then the Warranty was invalidated. But the farmer would not let it go, he contacted everyone within the company selling the tractor until he eventually discovered that by using this oil, the tractor would work in any place in the World from the coldest to the hottest. That's why the oil was specified. He got them to accept that it was OK for him to use the normal everyday oil used in his other Machinery. What I'm saying is, I don't see it as controversial to challenge the status Quo, the accepted way of doing things. In fact, to me, it appears a little stupid not to.
The other story that springs to mind is the people in a waiting room standing up by command. More HERE:-
Going back to Access, the thing that is intriguing me at the moment, the one I am trying to fathom out is whether you should use subs or functions. I have seen many people berated for not converting their functions into subs where possible. However I find this a time consuming and unnecessary process. Especially after a few times of having to convert them back into functions.
And then there's the case, I think it's in the event of a control, you actually have to use a function, you cannot use a subroutine, thereby being forced to break this rule by the construction of the software that the rule is a dictate of... I think of it a different way round, a routine for triggering an event for the control is always a subroutine. Now you could say this is because nothing is returned, however it also distinguishes between many of the routines built-in to Access, and the routines created by a programmer. So let's say you placed in the onclick event of a command button, in the onclick event of another command button. This is automatically blocked by this behaviour. I think it's some sort of protection, protection to stop the programmer calling control events from another control event.
So what have I actually said? What I'm saying is I challenge the rule that you should convert all functions to subroutines where possible. The reasoning, if you have a subroutine which you call from a control event, (=fMySub) then you have to convert that subroutine into a function for it to work. Thereby breaking this rule to actually use MS Access in the way it is designed. The design of MS Access actually forces you to break this rule! So why not break the rules across the board? In other words is it really a rule, or just one of those things that everyone believes to be a rule?
My answer to that is I think it's a protection built into the structure of MS Access, haven't proved this yet but you can experiment yourself if you try and call a subroutine from a controls event, the message you get indicates that the subroutine cannot be found. You can mimic this yourself, first of all create a function and call it from a control event, it works, change the function into a subroutine and it stops working. Change it back into a function and it works, now --- comment out the function, so it no longer exists, you get the same error message as if you were trying to call as a subroutine. In other words this indicates to me that the subroutine is not in the collection of objects available to the to the controls event only the only available options are [Event Procedure], [Macro] or =fMyFunction --- =fMySub is NOT ALLOWED!