VBA question regarding the me.* in code

  • Thread starter Thread starter iamrdbrown
  • Start date Start date
I

iamrdbrown

I am just beginning to learn VBA & have run across the following syntax in
some of the lessons I am following online:

'Retrieve the hourly salary
HourlySalary = CDbl(Me.txtHourlySalary)

My question (that isn't covered in my lesson) is this: Does the Me._____
identify that the information being looked for is on the current form/page?
Or does it mean something else entirely?

Thanks in advance for any help in clarifying this one.
R Brown
 
iamrdbrown said:
I am just beginning to learn VBA & have run across the following syntax in
some of the lessons I am following online:

'Retrieve the hourly salary
HourlySalary = CDbl(Me.txtHourlySalary)

My question (that isn't covered in my lesson) is this: Does the Me._____
identify that the information being looked for is on the current form/page?
Or does it mean something else entirely?

Thanks in advance for any help in clarifying this one.
R Brown

This is useful:

http://www.mvps.org/access/forms/frm0031.htm

Phil, London
 
Strictly speaking Me is a reference to the current instance of the class in
whose module the code is running, but think of it in terms of a reference to
the current form (or report) as mostly that's how it will be used.

To better understand its real meaning, you could for instance have more than
one instance of the same form open simultaneously, each at a different record
say. Now if, in one instance, you were to refer to a control on the form by
a full reference such as Forms!MyForm!MyControl there is no way of knowing
from this which instance of the form, and therefore which record, is referred
to. If Me.MyControl is used, however, then this refers to the control on
that instance of the form in whose module the code is running.

In most cases Me can in fact be omitted, but its best not to do so. Your
example would probably work just as well as:

HourlySalary = CDbl(txtHourlySalary)

One thing to note is that you can only use Me in VBA, don't use it in an
expression used as the ControlSource of a computed control for instance.
Normally in a case like that you'd just omit it, e.g. for an unbound
GrossPrice control you might have:

=[NetPrice] * (1+[TaxRate])

Though you can, but normally wouldn't, use the Form property in place of Me
in a case like this:

=Form.[NetPrice] * (1+Form.[TaxRate])

The Form property, as you'd expect returns a reference to the current form.
There are some situations where its useful, but mostly you'd omit it.

Ken Sheridan
Stafford, England
 
One last question (for now) on this topic - can you program for Access in
Visual Basic as opposed to VBA? If that is possible, I may look that
direction first...

Ken Sheridan said:
Strictly speaking Me is a reference to the current instance of the class in
whose module the code is running, but think of it in terms of a reference to
the current form (or report) as mostly that's how it will be used.

To better understand its real meaning, you could for instance have more than
one instance of the same form open simultaneously, each at a different record
say. Now if, in one instance, you were to refer to a control on the form by
a full reference such as Forms!MyForm!MyControl there is no way of knowing
from this which instance of the form, and therefore which record, is referred
to. If Me.MyControl is used, however, then this refers to the control on
that instance of the form in whose module the code is running.

In most cases Me can in fact be omitted, but its best not to do so. Your
example would probably work just as well as:

HourlySalary = CDbl(txtHourlySalary)

One thing to note is that you can only use Me in VBA, don't use it in an
expression used as the ControlSource of a computed control for instance.
Normally in a case like that you'd just omit it, e.g. for an unbound
GrossPrice control you might have:

=[NetPrice] * (1+[TaxRate])

Though you can, but normally wouldn't, use the Form property in place of Me
in a case like this:

=Form.[NetPrice] * (1+Form.[TaxRate])

The Form property, as you'd expect returns a reference to the current form.
There are some situations where its useful, but mostly you'd omit it.

Ken Sheridan
Stafford, England

iamrdbrown said:
I am just beginning to learn VBA & have run across the following syntax in
some of the lessons I am following online:

'Retrieve the hourly salary
HourlySalary = CDbl(Me.txtHourlySalary)

My question (that isn't covered in my lesson) is this: Does the Me._____
identify that the information being looked for is on the current form/page?
Or does it mean something else entirely?

Thanks in advance for any help in clarifying this one.
R Brown
 
iamrdbrown said:
One last question (for now) on this topic - can you program for Access in
Visual Basic as opposed to VBA? If that is possible, I may look that
direction first...

Ken Sheridan said:
Strictly speaking Me is a reference to the current instance of the class in
whose module the code is running, but think of it in terms of a reference to
the current form (or report) as mostly that's how it will be used.

To better understand its real meaning, you could for instance have more than
one instance of the same form open simultaneously, each at a different record
say. Now if, in one instance, you were to refer to a control on the form by
a full reference such as Forms!MyForm!MyControl there is no way of knowing
from this which instance of the form, and therefore which record, is referred
to. If Me.MyControl is used, however, then this refers to the control on
that instance of the form in whose module the code is running.

In most cases Me can in fact be omitted, but its best not to do so. Your
example would probably work just as well as:

HourlySalary = CDbl(txtHourlySalary)

One thing to note is that you can only use Me in VBA, don't use it in an
expression used as the ControlSource of a computed control for instance.
Normally in a case like that you'd just omit it, e.g. for an unbound
GrossPrice control you might have:

=[NetPrice] * (1+[TaxRate])

Though you can, but normally wouldn't, use the Form property in place of Me
in a case like this:

=Form.[NetPrice] * (1+Form.[TaxRate])

The Form property, as you'd expect returns a reference to the current form.
There are some situations where its useful, but mostly you'd omit it.

Ken Sheridan
Stafford, England

iamrdbrown said:
I am just beginning to learn VBA & have run across the following syntax in
some of the lessons I am following online:

'Retrieve the hourly salary
HourlySalary = CDbl(Me.txtHourlySalary)

My question (that isn't covered in my lesson) is this: Does the Me._____
identify that the information being looked for is on the current form/page?
Or does it mean something else entirely?

Thanks in advance for any help in clarifying this one.
R Brown


Yes you can. VBA is really VB without the ability to produce its own
forms - VBA uses the GUI of the host application (Word, Access, etc).
However, you can set references in VB to the Access library and/or
related libraries (DAO, ADO, etc) and have complete control. Note that
the last time I did this was well before the emergence of .NET, but I
understand that it's all still possible. However, you're adding
complexity and "wasting" the built-in integration which Access provides,
and I wonder what the motivation might be.

Phil, London
 
Philip Herlihy said:
Yes you can. VBA is really VB without the ability to produce its own
forms - VBA uses the GUI of the host application (Word, Access, etc).
However, you can set references in VB to the Access library and/or
related libraries (DAO, ADO, etc) and have complete control. Note that
the last time I did this was well before the emergence of .NET, but I
understand that it's all still possible. However, you're adding
complexity and "wasting" the built-in integration which Access provides,
and I wonder what the motivation might be.

Phil, London


No particular motivation other than I plan to learn VB in the near future &
would rather not muddy the waters with VBA (confusion comes naturally) any
more than is necessary. The company I work for uses a lot of computer based
electronic test equipment & Access is just a small portion of what I might
need to be able to work with.

R. Brown
 
iamrdbrown said:
No particular motivation other than I plan to learn VB in the near future &
would rather not muddy the waters with VBA (confusion comes naturally) any
more than is necessary. The company I work for uses a lot of computer based
electronic test equipment & Access is just a small portion of what I might
need to be able to work with.

This depends on what you mean by VB. VB 6.0 or VB.Net. If VB 6.0 it
will be very similar but with quirks such as different ways of opening
forms. If VB.Net then there are major differences and enough that
folks familiar with VB 6.0, VB.Net and C# have suggested using C#
instead of VB.Net. Especially if you have to go back and forth
between VB6 and a .Net environment. Of course you may not have this
luxury.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
 
This depends on what you mean by VB. VB 6.0 or VB.Net. If VB 6.0 it
will be very similar but with quirks such as different ways of opening
forms. If VB.Net then there are major differences and enough that
folks familiar with VB 6.0, VB.Net and C# have suggested using C#
instead of VB.Net. Especially if you have to go back and forth
between VB6 and a .Net environment. Of course you may not have this
luxury.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

I do have that luxury (sort of)... I am teaching myself all of this. Our
current software is VB6 for the most part, but we would like to see it go
..net and having me understand the programming aspect will help with that. My
background (in college) was Basic and Paschal - many moons ago. I remember
just enough about Paschal to be dangerous - no syntax, just concepts. If C#
is the better option for being able to program for Access (and potentially
SQL later), then that is where I will direct my focus.

Thanks,
R Brown
 
iamrdbrown said:
If C#
is the better option for being able to program for Access (and potentially
SQL later), then that is where I will direct my focus.

C# is not supported within Access. Only VBA is which is basically the
same IDE as VB6. I only mentioned C# in the event that you were going
to move to a new programming language/environment.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
 
Back
Top