Tags: access, database, fieldname, mefieldname, microsoft, mysql, oracle, sql

Difference between Me! and Me.

On Database » Microsoft Access

12,555 words with 8 Comments; publish: Thu, 05 Jun 2008 11:10:00 GMT; (250156.25, « »)

What is the difference between Me!fieldName and Me.FieldName when coding...

All Comments

Leave a comment...

  • 8 Comments
    • dot is something inherent to Access. Me.Name, Me.Recordsource

      Bang ! is something that was made by the developer. Me!txtFirstName

      Me!cboState

      Steve Clark, Access MVP

      http://www.fmsinc.com/consulting

      *FREE* Access Tips: http://www.fmsinc.com/free/tips.html

      "JOM" <JOM.ms-access.todaysummary.com.discussions.microsoft.com> wrote in message

      news:DBD7A41A-902D-41A7-AEE3-F876FE63E627.ms-access.todaysummary.com.microsoft.com...

      > What is the difference between Me!fieldName and Me.FieldName when

      > coding...

      #1; Thu, 05 Jun 2008 11:11:00 GMT
    • I may be wrong about this, but let me try to explain how I understand.

      The DOT (.)operator references properties of the form, whereas the

      BANG (!) operator references controls that the developer creates.

      So, you might reference these things in code ...

      Me.Dirty = False

      Me.Caption = "My First Form -- Hello World"

      If your form has a recordsource behind it, you could also do this ...

      lngID = Me.PersonID

      Me.EditDate = Date()

      Because the form has a bound recordset, the fields of the query are

      properties of the form, even when they are not added as controls.

      However, if you add a control named EditDate (or better yet, txtEditDate)

      then you would access it like this ...

      Me!EditDate.Enabled = True

      ... to refer to your text box, but it gets confusing, doesn't it. How do

      you know if you're pointing to the text box, and not the field. You cannot

      Enable a field of the recordset, but can enable a control. So, I always

      name my controls in such a way that they are distinguished from fields.

      Me.txtEditDate.BackColor = vbRed

      Make sense?

      Danny J. Lesandrini

      dlesandrini.ms-access.todaysummary.com.hotmail.com

      http://amazecreations.com/datafast

      "JOM" <JOM.ms-access.todaysummary.com.discussions.microsoft.com> wrote ...

      > What is the difference between Me!fieldName and Me.FieldName when coding...

      #2; Thu, 05 Jun 2008 11:12:00 GMT
    • Here is something Dirk Goldgar wrote in February in this forum (acutally, it

      was in modulesdaovba). I kept if for reference, as it explains the matter

      quite succinctly:

      -- BANG (!) vs. DOT (.) --

      It's not so much a question of one or the other being "proper syntax", but

      that they mean different things that nevertheless almost always give the

      same result. As I understand it, the bang (!) notation specifically denotes

      that what follows is a member of a collection; in this case, a member of

      the form object's default collection, the Controls collection. The dot (.)

      notation denotes that what follows is a property or method of the preceding

      object. That would logically make the bang notation "proper" and the dot

      notation improper.

      But wait. Wherever possible, Access makes the controls on a form and the

      fields in its recordsource all available as properties of the form. It also

      makes the fields of the recordsource available via the bang notation. I'm

      not sure exactly how it does this; maybe if a name is not found in the

      Controls collection it checks the Fields collection of the form's recordset

      as a fallback position. So for most practical purposes Me!ControlName and

      Me.ControlName evaluate to the same thing, and the timing tests I've seen

      suggest that there is little to choose between them as far as execution

      efficiency is concerned. I seem to recall that there is a very slight

      difference, but I can't remember which way the advantage lies, and it's not

      much. There's a coding-time advantage, however, to using the dot notation,

      as it makes the "intellisense" dropdown lists available. That's a strong

      argument for using the dot notation, in my book.

      But wait again! I said above that Access makes the controls available as

      properties "wherever possible". There are cases where it can't do that.

      Specifically, it can't do it when there is already a property of the same

      name as the control in question. For example, if your form "Form1" has a

      control or a field foolishly named "Name", currently displaying the value

      "John Doe", then executing this statement in the form's code module:

      Debug.Print Me!Name, Me.Name

      will print

      John Doe Form1

      in the Immediate Window. So you must be careful not to use any reserved

      words or built-in properties as names for your controls, if you want to use

      the dot notation to refer to them. But then, you should avoid doing that

      anyway, as it tends in general to confuse poor Access.

      "JOM" <JOM.ms-access.todaysummary.com.discussions.microsoft.com> wrote in message

      news:DBD7A41A-902D-41A7-AEE3-F876FE63E627.ms-access.todaysummary.com.microsoft.com...

      > What is the difference between Me!fieldName and Me.FieldName when

      > coding...

      #3; Thu, 05 Jun 2008 11:13:00 GMT
    • In addition to all the good answers you've already received, see what Andy

      Baron had to say at http://doc.advisor.com/doc/05352

      Doug Steele, Microsoft Access MVP

      http://I.Am/DougSteele

      (no private e-mails, please)

      "JOM" <JOM.ms-access.todaysummary.com.discussions.microsoft.com> wrote in message

      news:DBD7A41A-902D-41A7-AEE3-F876FE63E627.ms-access.todaysummary.com.microsoft.com...

      > What is the difference between Me!fieldName and Me.FieldName when

      > coding...

      #4; Thu, 05 Jun 2008 11:14:00 GMT
    • The one lesson I can add to this whole thing is that use of the .dot is

      resolved at compile time.

      So, if you are changing the reocrdsource of a form in code, and do NOT have

      a control on the form, then using the .dot will cause a compile error if the

      underlying field is NOT included in the forms reocrdsource...

      So, really, the rule I use here is

      .dot - for controls

      !bang - for record source data. Since if you change the

      reocordsource of a form, then your code will NOT break, and you do NOT have

      to pile out a whole bunch of un-used controls somewhere on the form JUST to

      continue using the .dot notation. I often see some access applications where

      there is a whole "pile" of controls shoved up in some corner (with visible =

      false) just so the developer could continue using the dot notation. You MUST

      have a control on the form if you change the forms reocrdsource..and use dot

      notation. The dot notation is resolved at compile time. The bang notation

      does NOT requite that you have a control on the form to reference the

      underlying data.

      Albert D. Kallal (Access MVP)

      Edmonton, Alberta Canada

      pleaseNOOSpamKallal.ms-access.todaysummary.com.msn.com

      http://www.members.shaw.ca/AlbertKallal

      #5; Thu, 05 Jun 2008 11:15:00 GMT
    • I have some questions regarding this statement in Andy Baron's article:

      "If you add fields to the recordsource query without resetting the

      recordsource property, or if you change the recordsource in code, any new

      fields won't automatically be added as properties. Also, remember that

      recordset fields still require bangs, since they haven't been implemented as

      properties."

      While this explains some instances when dot notation does not work, I don't

      know what is meant about resetting the recordsource property. If I am using

      a query as the recordsource I suppose I could switch to the table, save the

      form, then change it back to the query. Would I then be able to use the dot

      notation? If so, is there a better way?

      Also, what is meant by "recordset fields"?

      "Albert D.Kallal" <PleaseNOOOsPAMmkallal.ms-access.todaysummary.com.msn.com> wrote in message

      news:eAGOxxMTGHA.4452.ms-access.todaysummary.com.TK2MSFTNGP12.phx.gbl...

      > The one lesson I can add to this whole thing is that use of the .dot is

      > resolved at compile time.

      > So, if you are changing the reocrdsource of a form in code, and do NOT

      > have a control on the form, then using the .dot will cause a compile error

      > if the underlying field is NOT included in the forms reocrdsource...

      > So, really, the rule I use here is

      > .dot - for controls

      > !bang - for record source data. Since if you change the

      > reocordsource of a form, then your code will NOT break, and you do NOT

      > have to pile out a whole bunch of un-used controls somewhere on the form

      > JUST to continue using the .dot notation. I often see some access

      > applications where there is a whole "pile" of controls shoved up in some

      > corner (with visible = false) just so the developer could continue using

      > the dot notation. You MUST have a control on the form if you change the

      > forms reocrdsource..and use dot notation. The dot notation is resolved at

      > compile time. The bang notation does NOT requite that you have a control

      > on the form to reference the underlying data.

      >

      > --

      > Albert D. Kallal (Access MVP)

      > Edmonton, Alberta Canada

      > pleaseNOOSpamKallal.ms-access.todaysummary.com.msn.com

      > http://www.members.shaw.ca/AlbertKallal

      >

      #6; Thu, 05 Jun 2008 11:16:00 GMT
    • "BruceM" <bamoob.ms-access.todaysummary.com.yawwhodawtcalm.not> wrote in message

      news:uLdRDUOTGHA.4864.ms-access.todaysummary.com.TK2MSFTNGP12.phx.gbl

      > I have some questions regarding this statement in Andy Baron's

      > article:

      > "If you add fields to the recordsource query without resetting the

      > recordsource property, or if you change the recordsource in code, any

      > new fields won't automatically be added as properties. Also, remember

      > that recordset fields still require bangs, since they haven't been

      > implemented as properties."

      > While this explains some instances when dot notation does not work, I

      > don't know what is meant about resetting the recordsource property.

      > If I am using a query as the recordsource I suppose I could switch to

      > the table, save the form, then change it back to the query. Would I

      > then be able to use the dot notation? If so, is there a better way?

      If you change the form's recordsource *property*, as by executing the

      statement

      Me.RecordSource = "SELECT A, B, C FROM Table1"

      or even

      Me.RecordSource = Me.RecordSource

      then the fields in the recordsource will be added to the form as

      properties, and any fields that had previously been added as properties

      but are no longer present in the recordsource will be removed.

      > Also, what is meant by "recordset fields"?

      I think he's referring to the fields in a Recordset object. Given a DAO

      or ADODB Recordset rs, you can't refer to a field in it using a notation

      like this:

      rs.Field1 = "foo" ' INCORRECT NOTATION

      Dirk Goldgar, MS Access MVP

      www.datagnostics.com

      (please reply to the newsgroup)

      #7; Thu, 05 Jun 2008 11:17:00 GMT
    • Thanks for the reply. I'm not quite sure how or if I'll use the

      information, but understanding is built one piece at a time.

      "Dirk Goldgar" <dg.ms-access.todaysummary.com.NOdataSPAMgnostics.com> wrote in message

      news:uW4bdQSTGHA.2276.ms-access.todaysummary.com.tk2msftngp13.phx.gbl...

      > "BruceM" <bamoob.ms-access.todaysummary.com.yawwhodawtcalm.not> wrote in message

      > news:uLdRDUOTGHA.4864.ms-access.todaysummary.com.TK2MSFTNGP12.phx.gbl

      > If you change the form's recordsource *property*, as by executing the

      > statement

      > Me.RecordSource = "SELECT A, B, C FROM Table1"

      > or even

      > Me.RecordSource = Me.RecordSource

      > then the fields in the recordsource will be added to the form as

      > properties, and any fields that had previously been added as properties

      > but are no longer present in the recordsource will be removed.

      >

      > I think he's referring to the fields in a Recordset object. Given a DAO

      > or ADODB Recordset rs, you can't refer to a field in it using a notation

      > like this:

      > rs.Field1 = "foo" ' INCORRECT NOTATION

      > --

      > Dirk Goldgar, MS Access MVP

      > www.datagnostics.com

      > (please reply to the newsgroup)

      >

      #8; Thu, 05 Jun 2008 11:18:00 GMT