There are some pros/cons.
However, the use of the me keyword is most certainly preferable as OFTEN you
do need to qualify the object you are referencing.
It provides clarity as to if you are referencing a variable, or a field in
the forms underlying data.
In addition, if you have a form that is un-bound, and you set the
recordsouce in code at load time (ie: just stuff the sql into the forms
reocrdsouce like:
me.ReocordSouce = "select * from main where City = 'Edmonton'"
Now, if your form has several fields from the underlying reocrdset that you
need to set/use in code, but not display on the form, then the following
will work:
me!LastEdit = now()
However,
LastEdit = now()
Will NOT WORK!!
If you don't use me, then access will generate a error. So, either you must
qualify the reference with me!, or you actually must put a text box control
on the screen called LastEdit to allow you to reference/use values from the
forms underlying recordset.
So, not using me! means you will have to clutter up the form with textboxes
for EACH field value that you need to reference. Further, if you delete, or
remove text box controls, you again can create errors. Using me! works
regardless if you place a text box control on the form or not (again, this
whole thing ONLY applies in the case where you CHANGE THE forms record
source).
As you begin to write more code, you will find often that you do change the
source of a forms data in code, and the instant you start doing that, then
your existing code will start to break. You are relying on the fact of a
forms recordsouce being set at design time as opposed to run time.
I can certainly agree that MOST forms data source is set at design time, but
often the need arises to change this, and when it does...your coding
practices will not work.
Note that I OFTEN reference text controls on the screen without qualifying
them with the use of me! However, I do this more often with un-bound text
controls. Thus, when I need to modify the forms underlying recorddata, then
I STILL do still use me!
