What can ME. reference?

[JamesDeckert]

I've inherited a db and I'm getting a compile error in my changed version (imported all objects from the old version and made some code changes) which the original version does not error when compiled.
It is on the following line
lngJobID = Me.JobID.Value
It gives the error "Method or data member not found" and highlights JobID
If I change the code to Me!JobID.Value the error goes away. But now I have many lines to change to bang instead of . throughout the entire db as other forms are doing the same kind of referencing with a period.

So a couple of questions.
1. When I go to design view of the form and look in the property sheet dropdown "JobID" isn't listed. What other things besides a form control can "Me" be referencing, or why can't I see JobID in the dropdown? It can't reference parent or subform controls using this syntax, can it? A record source field name? The dropdown can't be filtered based on what is selected on the form, or any other way, can it?

2. Any idea why the new version of the db won't accept . whereas the old db did? The intellisense on the new db doesn't show any controls starting with 'J' after typing Me. But the old db shows 5. They are not viewable from the property sheet dropdown on the old db either.

[ItsMe]

I am not following everything you are saying, perfectly. So I will start by addressing the question regarding Me. ...

There is a difference between the dot (.) Access Operator and the bang (!) Access Operator. The bang is an access operator to access the default member of whatever namespace is placed before it. The way I understand it and I could be wrong, the dot (.) access operator is used to access the members of an object. So if a class is not yet instantiated as an object, the dot operator will not work. Here is a more detailed explanation regarding the Bang Access Operator
http://bytecomb.com/the-bang-exclama...erator-in-vba/

What your problem is, exactly, seems to be you have managed to rename the controls on a form. Why this is a problem, I am not sure. As far as I know, as long as the form is open and instantiated, if Me!FieldName works, so should Me.FieldName. I think it is importatnt for you to distinguish what it is that has changed from before (when it worked) and now (it does not work). There seems to be some missing information.

Having said that, I will always use Me!FieldName and Me.ControlName.Value behind a Form or Report. I do it this way because I feel confident Me!FieldName is the current value of that fieldname for the Report or Forms' RecordSet and Me.ControlName.Value is the current value of a specific control.

[JamesDeckert]

The code is erroring on a form I have not touched. All objects (tables/forms/reports/modules etc) were imported from the original db into a newly created blank db. I decided to do a find/replace of Me.JobID with Me!JobID and after 250 changes (on many forms), now a different Me.whatever is erroring on compile.

Can Me.JobID.Value be referencing anything but a textbox (or other) control on the form? If not, why can't I see it in the dropdown on the property sheet of the form in the new db or the original db?

BTW: great post on Bang

[ItsMe]

...
Can Me.JobID.Value be referencing anything but a textbox (or other) control on the form? If not, why can't I see it in the dropdown on the property sheet of the form in the new db or the original db?
...

Yes, I think the reason rhymes with corruption. I can't think of any other reason. Like I said, you are going to have to narrow it down to what is different from then and now. If the only thing changed is an Import. Then, the Import is bad. When you look at a copy of the original, it compiles? Corruption is what makes sense here. Otherwise, why would the control names be all goofy? Do the control names match between the two files?