[AccessD] You just gotta do it - was Languages and Tags

Max,

I have to say that your solution to load the translation in design view and then save the form was 
good.  Many years ago (late 90s) I wrote a security system where I did something very similar.  I 
was trying to implement a method of securing controls on forms and even the forms themselves such 
that specific users could see controls, some could edit them etc.  I used tables to hold all that 
stuff for setting up and editing the security, then loaded the stuff into the tags just as you are 
doing in your last example (but in design view) then saving the forms.

It worked surprisingly well, and I used that for a couple of years.  That was before I discovered 
collections.  Once I discovered collections (but before classes) I ended up with collections of 
"properties" loaded into the form header.  I even had collections of collections.  It was at that 
time that I moved away from using tags at all.  The collections, and collections of collections 
worked much better than the tags but holy crap the code was tough.  I was a good enough programmer 
to make it work but looking back it was just tough code!

Once I learned Classes, it all just fell into place.  Before classes I would use a collection to 
store other collections.  The "base" collection (which stored other collections) is now replaced by 
my "supervisor" class. The other collection was replaced by a class as well.

You see the thing about classes is that they can hold TONS of variables for storing all kinds of 
properties about the object you are modeling.  Once you create that class, it can be manipulated 
from another class, and the properties become the dot syntax that we all know and love.

As an example:

frm.Controls(strControlName)

What is Controls?  A collection.  What is form?  A class!  Literally, form is a class (just like the 
classes YOU can create) and it has a collection (just like you can dimension) that holds it's 
collection of controls.  When you as a programmer reference it, you reference form.controls(SomeIndex).

You use classes and properties of classes every day of your Access programming life!!!  What you 
have not learned yet is to create your own classes, and when and why you would do so.  That is what 
my lecture series is designed to do is to lead you to classes.  There are TONS of Access programmers 
who are good programmers but not "class developers".  You USE classes because you USE the objects 
which Access provides, but you don't "get" that these objects you use every day are just classes as 
well and YOU can do things exactly like that!

Dim app As Application
     app.CommandBars
     app.DataAccessPages
     app.Forms
     app.Modules
     app.Printers
     app.References
     app.Reports

App is a CLASS.  All of the other things listed are collections that the Application class uses to 
store multiple instances of... OTHER CLASSES.

A command bar is a CLASS.  A DataAccessPage is a CLASS.  A Form is a CLASS.

Almost all of these classes have their own collections, and each of those collections are loaded 
with... CLASSES!!!

EVERYTHING in Access is a CLASS, and every class has collections too hold other ... CLASSES.

If you guys ever wish to be GREAT programmers (and you can be!) you just have to figure out classes 
and collections (and events, and properties).  You already USE them, though you may have never 
understood that you do.  Now learn how to make your own!!!

I will help you learn this stuff.  I am here, read the lectures, ask your questions.

A "Guru" is nothing more than ME with a little (OK in my case maybe a LOT) more knowledge.  They are 
still a Guru, but if I can learn what they know then I become a Guru (in that area of knowledge). 
Being a Guru is not the objective though, the objective is to be able to do those things that seem 
so easy to the Guru.

Folks, classes are not rocket science, they are easy.  They just take practice.

John W. Colby
www.ColbyConsulting.com