Form code references form things

Private Sub Form_Current()

470 If IsNull(VenueID) Then
480 cboVenueID = "<unknown venue>"
490 Else
500 cboVenueID = VenueID
510 End If

End Sub

There's no declaration. VenueID is a field in the recordsource of the form.
This code compiles. Should it? Shouldn't that reference be

If IsNull(Me!VenueID) Then blah blah

Or rather, it's compiled for 6 months and now on a clients machine I get
masses of compile errors, all complaining about unknown variables,
obviously. Why can that compile when the code can't know what VenueID is?

Yours, Mike

I can't say whether the problem still exists in later versions, because I
developed the habit of always using Me!. If you have a bunch of field or
control references in the code, With ... End With can come in very useful
here:

With Me
If IsNull(!SomeField) Then
!SomeControl = Whatever
Else
'etc
End If
End With

--
Brendan Reynolds
bren...@indigo.ie

"Mike MacSween" <mike.macswee...@btinternet.com> wrote in message
news:3ea70119$0$66678$bed6...@pubnews.gradwell.net...

HTH

Andy.

Let me get this straight. In any code behind form it should be possible to
refer to fields and controls on the form WITHOUT using Me! ? But that it
doesn't always work? Are form controls and fields like implicit variables or
something? If so what happens if you actually declare a variable with the
same name. Well let's try it......nope don't get any sort of 'duplicate'
message.

What's going on here? This code compiled on one machine but not on another!

Cheers, Mike

"Brendan Reynolds" <bren...@indigo.ie> wrote in message
news:ntDpa.9993$pK2....@news.indigo.ie...

Cheers Mike

"Andy" <system....@ntlworld.com> wrote in message
news:1wDpa.2029$pR6...@newsfep4-winn.server.ntli.net...

--
Brendan Reynolds
bren...@indigo.ie

news:3ea7074d$0$66672$bed6...@pubnews.gradwell.net...

Cheers,
Pavel

"Pavel Romashkin" <pavel_r...@hotmail.com> wrote in message
news:3EA71980...@hotmail.com...

No, that's incorrect.

IsNull() is a function that takes a variant as an argument. It
returns True or False based on whether or not the value passed to
it is Null or not.

I don't know what Mike's problem is here, though in yesterday's
version of this thread, he said that occasionally Format() and
other builtin functions were not working, so there's clearly
something wrong on the target machines.

For what it's worth, while Access allows you to not specify the Me
of the control, it is simply not a good idea, in my opinion.

Think about encountering someone else's code where they haven't
used any naming conventions for variables and have not use Me for
their control references. How will you figure out what's a variable
and what's a control? No, it's not impossible at all, but with
Me!ControlName you don't have any ambiguity (well, I guess there
could be custom properties, too).

And, of course, I also recommend ! over ., with the loss that
control names are not checked by the compiler as they are with the
. operator.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

Thanks David. That's what I thought.

Basically the problem is with knackered installs of Office 2000 on the
target machines I think. I didn't check, but I'm willing to guess that no
service packs have been installed there. About 6 months ago I tried to
upgrade with service packs, and couldn't, tried to uninstall in order to
reinstall, and couldn't do that either. Lots of complaining about 'not a
Windows installer' or something. I'll try yet again this weekend, when the
clients office will be completely empty apart from me cursing Access 2000.

Yes, Format() wouldn't work, so I assume the VBA reference is screwy, in
some way. But a full import into a new database seemed to fix that on one
machine 6 months ago. This time on a different machine (I thought!) it
didn't, and I got the unknown variable stuff on compile. Well, actually when
I installed. But presumably that decompiles. Then one of the staff told me
that the machines had all been swapped round, and the one I was trying to
install on, unsuccessfully, is in fact the one that I did install on
successfully (eventually), 6 months ago.

What's depressing is that I'm going to have to go through this frigging
charade a dozen times on each machine now. And any fantasy I might have
about doing some automatic version upgrades by installing new versions on
the server and do some fancy batch stuff is out the window, as I'll have to
be in attendance just waiting for the first time each user runs the app,
waiting for it too crash.

So an app that compiles successfully on my dev machine won't on the target.
What sort of lunacy is that?

Actually I never knew that. One of the non-compilers is a straight copy out
of a book (dare I say, Getz!) and no doubt the other was where I wasn't
thinking straight. I normally would Me! or maybe Me. everything. But
obviously it compiled so I was none the wiser. Is there any sort of sense or
rule about all this? Or even a setting - 'don't allow form references
without Me' or something.

I'm pretty sure that its the VBA library on the target machine that's up
creek minus paddle. So I'll have to sort that out.

You know, it's this sort of thing that makes me think that you and the other
anti A2Kers are right. I've done a lot of similar work with an Access 97
application, swapping back and forth between development machines and target
machines and encountered NOTHING like this atall. Even though the target
machine is just as poorly set up and maladministered. So right now, instead
of paying attention to a useful user interface, or trying to implement any
of the client's awkward last minute requests to look like a generous
computer super hero, I'll have to piss about making something work that
should do out of the box. And the clients won't know. If I spend 8 hours
making Access 2K do what it's meant to they'll just think I don't know what
I'm doing.

One last time for the hard of hearing then -

! is used for user named things. By which I mean stuff I've created.

. for built in properties and methods and collections.

Yes?

But you can use . if you want the intellisense, and the compiler checks it
too (I never knew that). So what's the advantage of !? (this is starting to
look like something out of a Captain Marvel comic)

Yours, Mike MacSween

There is no such setting.

I would recommend using Me! at all times, in all circumstances,
with no exceptions, ever.

Have you decompiled and tried recompiling on the target machine?
I've seen (even with A97) different installed versions of the main
VBA dll cause code to fail and even IPFs that completely crash
Access. A decompile and recompile on target machine has almost
always fixed it when I've encountered, but that has only ever been
in A97, not A2K, where I've never encountered that kind of problem.

The key problem is that you *must* start from fresh, uncompiled
code to be sure you've gotten rid of all the problems in
conditionally compiled code.

As a preventative measure, it's a necessity that you turn off
CONDITIONAL COMPILING. MichKa explains why here:

http://trigeminal.com/usenet/usenet004.asp

I actually disagree with Michael's final conclusion, that you can
use DECOMPILE too much, but I don't code in A2K (except for one
relatively trivial app), so I'm not exposed to the issues caused by
the monolithic save model and corruption.

To turn off conditional compiling, go to the Options in the VBE
window and turn off COMPILE ON DEMAND. The help for A2K is rather
different in what it says than A97. A97 says this:

Select to automatically compile a module, if necessary, when
you execute a procedure in that module. Clear to automatically
compile a module and all potentially called modules when you
execute a procedure in that module.

A2K help says:

Compile On Demand — Determines whether a project is fully
compiled before it starts, or whether code is compiled as
needed, allowing the application to start sooner.

Background Compile — Determines whether idle time is used
during run time to finish compiling the project in the
background. Background Compile can improve run time execution
speed. This feature is not available unless Compile on Demand
is also se lected.

Given the monolothic save model in A2K and no module-level
security, it's pretty clear that in A2K it's all or nothing --
either the whole project is compiled or it's not, and you can't
incrementally compile individual modules (note the lack of COMPILE
options in the A2K Debug menu as compared to A97).

If you don't compile your app before distribution, there will be a
slowdown the first time the app is used when the whole thing is
compiled. In A97, this slowdown was distributed among the objects
with code (i.e., a report's module didn't get compiled until it was
opened).

In either case, the proper way to distribute is to compile before
releasing it for distribution.

My regular work cycle involves coding, and decompiling/recompiling
before distributing for testing. I regular manually compile while
coding, because I want to make sure I haven't broken anything.

Why does this cause problems?

Well, as I understand it, conditional compiling relies on flags
that tell the compiler whether a block of canonical code (what you
type) has been compiled or not. When you COMPILE ALL, the lines
marked as already compiled are not recompiled. This saves time, of
course, but it can mean that if things are kind of dodgy, errors
may not be reported during the compile.

This is why I decompile often, because I want to be sure that the
whole thing works.

While I'm on the subject of DECOMPILE, some important points:

1. work with COMPILE ON DEMAND set to FALSE.

2. manually compile your code as you work.

3. periodically compact/repair the database, then decompile it.

4. never continue working in an instance of Access started with the
DECOMPILE switch -- always exit immediately after the decompile is
finished and re-open your MDB in a new instance of Access.

5. when you open a freshly decompiled database, be sure you compact
it before you recompile. Why? Because then you insure that the
internal data pages in your MDB that were marked as
discardable/unused in the decompile process will *really* be
discarde. You can test this by decompiling, then recompiling then
compacting, and compare the file size to decompiling, compacting,
recompiling and compacting. In many cases (it actually depends on
the amount and kind of code you have; I've found that with class
modules the problem is worse), you'll find that when you skip the
first compact, you end up with a larger file, even though the data
pages should have been discarded. That means that lurking there in
your MDB are some data pages that are supposed to be discarded and,
for whatever reason, the compact is keeping them, which suggests
that some pointer in the db thinks those compiled code pages are
still valid and usable. That, in turn, suggests the possibility,
however remote, that a recompile will not really create fresh
compiled p-code, but point to some of those pages that were
supposedly discarded.

I'm not saying this happens.

What I *am* saying is that if you compact after the decompile (in a
new instance of Access, not the one in which you decompiled), you
won't be able to have the remote problem that I described above,
because the pages won't be there any more.

Again, I'm not saying they *do* get used, just that a compact
insures that they *can't* be used.

So, the decompile process goes like this:

A. make a backup copy

B. compact

C. decompile

D. close Access

E. open a new instance and compact

F. compile

G. compact

Don't skip any of the steps!

Well, most of my coding is done in A97 for distribution to be used
in A2K. So, I do my decompile/compact cycle in A97, then convert to
A2K, which imports, compacts, compiles and then compacts. All the
code (and the compilation) is brand-new and fully compiled.

For the one project I'm currently doing in A2K, I just do a
compile/compact cycle before distribution.

I tend not to decompile as often in A2K because I'm aware that I'm
walking on thinner ice because of the way the Access project is
stored as a single data stream in one record instead of as multiple
streams in multiple records (one for each object, more or less).
One corruption in that one record and maybe the whole project goes
south.

No, that's not correct.

Me! is used for items in the Controls and Fields collections of a
form or report. If there is both a control and a field with the
same name, the reference resolves to the control. This is one of
the many reasons why it is a good idea never to have controls that
will be referred to in code (or in expressions in control or form
properties) named exactly the same as the underlying fields, as you
are depending on Access to guess exactly which one you are
referring to.

The . is used for properties and methods of the form.

In recordsets, the ! operator is used for the default Fields
collection, the . for properties and methods of the recordset, just
like in forms/reports.

In standalone class modules, Me can use only the . as there is no
default collection(s).

As I said, not exactly. You can create custom properties of a form
(something you created) and it will require the . operator.

>checks it too (I never knew that). . . .

When using the ! you can get Intellisense by hitting Ctrl-Space
(thanks to Joan Wild for this one!).

> . . . So what's the advantage of !?

The advantage of ! is:

1. lack of ambiguity -- if it's referred to with ! then you know
that it is a control or field.

2. stability -- use of the . causes certain kinds of near
irreparable corruption under certain as yet undefined
circumstances.

I never, ever use the . operator for references to controls/fields
for these two reasons.

But others disagree with me on this.

Wow! Thanks for all that. I've just started using /decompile a little so
good to get some more info on it. I've seen MichKa's article before. I'll
pay attention to that over the weekend, I think I'm going to need it.

And thanks for the !/. thing. And to Joan Wild, via you for the Ctrl-Space
tip.

Cheers, Mike

Me for one.
Or should that be Me. for one ;-)

Wayne Gillespie
Gosford NSW Australia

While I agree with this 100% for A97, I'm not so sure that a compact in A2K/A2K2
will actually remove the dead pages.

I have noticed consistently in A2K2 that regularly compacting does NOT return
the file to a (relatively) standard filesize. The compacted filesize will
continue to grow as you develope the database regardless of what changes you are
making.

There appears to be a lot of crap in the A2K/A2K2 files that are NOT removed by
compacting or decompile/compacting. Whether this dross includes discarded code
pages I don't know, but it is clear there is a lot of residue.

Before delivering an A97 file I compact / decompile / compact / compile /
compact to ensure a clean file as you suggest.

With A2K/A2K2 I always create a new db and import all objects from my dev file
and then compact, to ensure a "clean" file is delivered. This generally results
in a filesize substantially smaller than the decompiled/compacted file.

Just for balance.

I ALWAYS use Me. when referring to controls on forms, never Me!
I (almost) ALWAYS give the control the same name as the field it is bound to.

In 8 1/2 years of working with Access I have NEVER had a single problem of any
kind related to these 2 practices, nor has anyone to my knowledge, been able to
provide a reproducible scenario demonstrating problems associated with these
methods.

I am not saying that these alleged problems don't exist, bit I feel that if I
have never encountered them in the millions of lines of code I have written in
Access in 8 1/2 years, then these alleged problems are extremely remote. Far to
remote, in my opinion, to warrant a global change from Me. to Me! and far to
remote, in my opinion, to warrant alerts of impending doom if you do not change
your ways.

IMO it is a non issue.

Others disagree with me on this ;-)

My practices and experience are identical to yours.

Interesting about using the same name for controls as the underlying field.
I can't remember having a problem on a form with that, but am sure it's
given me problems on reports.

Thanks for your feedback.

Mike

"Rick Brandt" <rvtjb...@sbcglobal.net> wrote in message
news:b8co7f$8ed5l$1...@ID-98015.news.dfncis.de...

Question: does the file then grow under normal use to the size it
was (more or less) before you created the new MDB? That is, does it
just go back up to where it was anyway?

I have only one app that is developed in A2K and haven't done
anything other than the same things I've done in A97. It's very
code-light, in comparison to most of my apps (I didn't create or
design it, I was just brought in to rescue it), and seems to
compact down very small. But I haven't compared to the size of
importing it into a new MDB.