Thanks for this as well Albert ... I haven't applied this solution as
yet but your response leads me to ask yet another question.
You have a Private Function MySelected() (and i'm noting again that
this is PRIVATE) yet MySelected shows up and has "value" in subs
CMDClick14 and CMDClick16.
How does it keep its value in those two subs?
The function when used each time will run the code inside of function. So I
think that even better then saying how does the function keep its value,
it's likely a little bit better or more clear to say how do the other
routines find and run that code each time? It is the code inside of that
function that runs to produce the result for that function.
This whole issue centers around what we call scope. You can even type in the
word scope in the help when in the vb editor to get a better explanation of
this issue. In a nutshell when you declare a module level function or
variable, it is available to ALL other functions within that module (they
are private to that ONE MODULE). So any particular function I happen to
create inside that forms module, is going to be available to all other
functions and routines within that module (they default to private, and it
not Even really necessary to use the private key word). Note any variables
declared at the beginning of the forms module will be available to all
routines within that module.
However if I want those functions (or variables at the start of the module)
to be used outside of that module, then I must declare them as public. So,
in our example we're going to be running some of that forms code outside of
the form. Therefore we have to change their decoration to public. So, the
private vs public does not affect any other routine within the same module,
but that key word only affects modules and code of out side of that module
(using Public "exposes" and allows other routines to use those
functions/variralbes. So, despite that function being private, that simply
means that ONLY all of the other code routines within that module are able
to use that particular function. As per my example we want/need to use that
code outside of that code module, and thus we must declare that function as
public function to expose that function to other forms and code modules that
may in turn want to call that particular piece of code.
Note that when you declare variables within a particular function, when the
function exits, all variables within that function go out of scope (and thus
cease to exist at that point in time). The next level is when you close the
form, all the variables and functions defined for that form then also ceased
to exist and go again what we call out of scope. The next level's when you
close the application any variables and functions defined within standard
code modules then go out of scope.
For the most part functions are not going to be used by another form, thus
might as well keep it private. Note this is usually not such a great problem
with forms modules, but it can be significant with that of standard code
modules. If you have ten standard code modules, and they each have a
function (or varible) with the same name, you best keep them private so
things don't step over each other and make things a confusing mess.
The more we can avoid global variables and the more we can reduce the scope
of the variables, the more reliable the application tends to be. And the
application becomes more durable of developers being able to make changes to
the code without breaking anything (changes in code will be less likey to
affect or damage or break other code routines that exist in the
application). In modern programming languages, we often refer to this
concept as encapsulation.
While MS access is not an "full" object oriented programming language, it
does have the ability to create your own custom class objects. I explain
this concept here:
http://www.members.shaw.ca/AlbertKallal/Articles/WhyClass.html