(Msg. 1) Posted: Mon Nov 03, 2008 8:47 am
Post subject: VBA question regarding the me.* in code Archived from groups: microsoft>public>access>gettingstarted (more info?)
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
(Msg. 2) Posted: Mon Nov 03, 2008 9:13 am
Post subject: RE: VBA question regarding the me.* in code [Login to view extended thread Info.] Archived from groups: per prev. post (more info?)
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" wrote:
> 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
(Msg. 3) Posted: Mon Nov 03, 2008 10:55 am
Post subject: RE: VBA question regarding the me.* in code [Login to view extended thread Info.] Archived from groups: per prev. post (more info?)
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" wrote:
> 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" wrote:
>
> > 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
>
(Msg. 4) Posted: Mon Nov 03, 2008 5:03 pm
Post subject: Re: VBA question regarding the me.* in code [Login to view extended thread Info.] Archived from groups: per prev. post (more info?)
iamrdbrown wrote:
> 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
(Msg. 5) Posted: Mon Nov 03, 2008 7:14 pm
Post subject: Re: VBA question regarding the me.* in code [Login to view extended thread Info.] Archived from groups: per prev. post (more info?)
iamrdbrown wrote:
> 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" wrote:
>
>> 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" wrote:
>>
>>> 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.
(Msg. 6) Posted: Mon Nov 03, 2008 7:14 pm
Post subject: Re: VBA question regarding the me.* in code [Login to view extended thread Info.] Archived from groups: per prev. post (more info?)
"Philip Herlihy" wrote:
> iamrdbrown wrote:
> > 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...
> 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.
(Msg. 7) Posted: Mon Nov 03, 2008 7:14 pm
Post subject: Re: VBA question regarding the me.* in code [Login to view extended thread Info.] Archived from groups: per prev. post (more info?)
iamrdbrown wrote:
>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/
(Msg. 8) Posted: Tue Nov 04, 2008 4:49 am
Post subject: Re: VBA question regarding the me.* in code [Login to view extended thread Info.] Archived from groups: per prev. post (more info?)
> 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.
All times are: Eastern Time (US & Canada) Goto page 1, 2
Page 1 of 2
You can post new topics in this forum You can reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum