Here's my recollection of Access 97, but I haven't used Access 97 for a
long time. There is no Form HasModule property in Access 97. The form
!!!Really!!!has to have a module, some piece of code, useful or not.
Private Sub Doolittle
Me.Visible=Me.Visible
End Sub

I doubt the second line is required. Then it all works swimmingly.

But that's my recollection only and subject to correction.

I hear that Mr Linson is old enough to qualify as Lucy's husband?
Australopithecus Afarenses, I believe.... long before Cro-Magnon...

8)

LOL! UG has spoken wise words.

A small caveat. When you do those things you mention, you have opened
the form. Probably it is hidden, but it's open.
And you may want to close it when you are done with it, although this
is not necessarily so. Because as we know, forms, visible or not, close
when Access closes; there is almost never any ghost form (although
Larry has been mistaken for one) hanging around.

Of course, when you talk about using the form's public methods you have
reached the stage where you have a class which does not need to be
intialized, (Dim cl as MyClass Set cl = New MyClass), if you need only
one copy of it, as the form has a default instance. And going back to
the form closing when Access closes, this "class" cleans up after
itself.

If you want to use controls on your forms for holding values, you can
enumerate these, much more easily than public class properties.

Of couse, if you need multiple copies of your class, you need to
initialize them as previously described. (with an array), or some other
way.

And last, (maybe), if you want to use Form as Class, you can mess with
its visibility turning it on again, off again to show messages,
progress, pictures of Lauren Bacall, whatever, as your class form runs.

At one time in Access 97 one could expose forms in library dbs; combine
this with the form as class idea and you can get to some very generic
type of objects for your library.  But forms do not seem to be so
exposable in Access >=2000

Enough! I run off at the mouth too much.

Form_Form1.Visible = True works for me.
I don't know what would prevent it from working for you.

The autocomplete issue is a red herring, as you can get autocomplete
with the ! by hitting Ctrl-Spacebar after you've typed a couple of
letters.

As to the compile time checking:

1. this depends on the fact that when you use Me.ControlName
(instead of Me!ControlName) you are depending on a mechanism over
which you have no control, a hidden wrapper that Access creates
around your control that behaves like a property of the form.

2. using the . syntax for controls on forms can very rarely lead to
some very severe kinds of corruption.

I use the ! exclusively for controls and don't need the compile-time
syntax checking. If you use Ctrl-Spacebar and pick from the list,
you never mistype. If you change a control name, you follow with a
Search/Replace in the code editor as the second step of the rename
process. This happens so seldom that I just don't feel it's worth
the corruption risk. The . method also offends my sensibilities as
objects on a form are not methods nor properties nor members of that
form (they are members of the default collection of the form).

There's another advantage to never using the . for controls or field
references, and that's that when you start referring to fields in
recordsets, you're accustomed to using ! so you never make the
mistake of trying to use the . in that context (which fails).

As to the Forms("frmMyForm") syntax, I use it only when using a
variable name to refer to an object in a collection. I have a
suspicion that it's slower than Forms!frmMyForm, but no actual
justification for that suspicion (and when I think about it, I
conclude that there probably isn't any performance difference).