467,915 Members | 1,150 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 467,915 developers. It's quick & easy.

When to use "." and when to use "!"

I'm still confused about this and I can't find anywhere that explains
it properly.

I have the MS book "Access 2003" in front of me and I'm reading Part 5
about VB and so on. It's telling me about how to refer to a specific
database and has the example:-

Dim dbMyDb As DAO.Database
Set dbMyDb = DBEngine.Workspaces(0).Databases(0)

but, but, but, but - what do those dots (periods, full stops, call
them what you will) mean? (OK, it appears to be the same usage as
C/C++/Java when referring to class/structure members, but I wish it
would tell me that somewhere)

Why are there dots used in referring to object members in this case
but when referring to controls on forms (for example) one uses "!".

Surely there must be somewhere that helps one understand this basic
syntax.

--
Chris Green

Apr 3 '06 #1
  • viewed: 1879
Share:
42 Replies
Generally, a dot exposes properties and methods and a bang (!) exposes
members of a collection. So forms!frmMyForm.Visible refers to the
visible property of frmMyForm, which is a member of the forms
collection. What makes this harder (or easier, depending on your
perspective) to grasp, is that Access has gotten more and more
forgiving about using the "wrong" notation.

Apr 3 '06 #2
us****@isbd.co.uk wrote in news:44316bba.0@entanet:
I'm still confused about this and I can't find anywhere that explains
it properly.

I have the MS book "Access 2003" in front of me and I'm reading Part 5
about VB and so on. It's telling me about how to refer to a specific
database and has the example:-

Dim dbMyDb As DAO.Database
Set dbMyDb = DBEngine.Workspaces(0).Databases(0)

but, but, but, but - what do those dots (periods, full stops, call
them what you will) mean? (OK, it appears to be the same usage as
C/C++/Java when referring to class/structure members, but I wish it
would tell me that somewhere)

Why are there dots used in referring to object members in this case
but when referring to controls on forms (for example) one uses "!".

Surely there must be somewhere that helps one understand this basic
syntax.


I always use .

It always works.

--
Lyle Fairfield
Apr 3 '06 #3
us****@isbd.co.uk wrote:
I'm still confused about this and I can't find anywhere that explains
it properly.

I have the MS book "Access 2003" in front of me and I'm reading Part 5
about VB and so on. It's telling me about how to refer to a specific
database and has the example:-

Dim dbMyDb As DAO.Database
Set dbMyDb = DBEngine.Workspaces(0).Databases(0)

but, but, but, but - what do those dots (periods, full stops, call
them what you will) mean? (OK, it appears to be the same usage as
C/C++/Java when referring to class/structure members, but I wish it
would tell me that somewhere)

Why are there dots used in referring to object members in this case
but when referring to controls on forms (for example) one uses "!".

Surely there must be somewhere that helps one understand this basic
syntax.

Well the book "Access 2003" does actually explain it further down the
same chapter - I should have kept reading. However it does seem
backwards to me using syntax like this before explaining it.

Mumble, mumble, moan, moan....... :-)

--
Chris Green

Apr 3 '06 #4
rkc
us****@isbd.co.uk wrote:
Well the book "Access 2003" does actually explain it further down the
same chapter - I should have kept reading. However it does seem
backwards to me using syntax like this before explaining it.


What does it say?
Apr 3 '06 #5
Per us****@isbd.co.uk:
Why are there dots used in referring to object members in this case
but when referring to controls on forms (for example) one uses "!".

Surely there must be somewhere that helps one understand this basic
syntax.


Dunno about the Good-Right-And-Holy-Path, but what I do is use a dot when doing
so allows auto complete to find the property and bang otherwise.

i.e. I'd use Me.txtWhatever because as soon as I type .t, Access will pop a
list of control names. OTOH, I'd use Forms!frmFund!txtWhatever to refer to
the same control from outside of the form's frame of reference.
--
PeteCresswell
Apr 3 '06 #6
us****@isbd.co.uk wrote in news:44316bba.0@entanet:
I'm still confused about this and I can't find anywhere that
explains it properly.

I have the MS book "Access 2003" in front of me and I'm
reading Part 5 about VB and so on. It's telling me about how
to refer to a specific database and has the example:-

Dim dbMyDb As DAO.Database
Set dbMyDb = DBEngine.Workspaces(0).Databases(0)

but, but, but, but - what do those dots (periods, full stops,
call them what you will) mean? (OK, it appears to be the same
usage as C/C++/Java when referring to class/structure members,
but I wish it would tell me that somewhere)

Why are there dots used in referring to object members in this
case but when referring to controls on forms (for example) one
uses "!".

Surely there must be somewhere that helps one understand this
basic syntax.

A google groups search will reveal many previous disacussions of
this. Basically the dot(.) refers to a property or method, while
a bang(!) refers to a member of a collection.

Since the controls on a form are members of that form's
collection, and the form itself is a member of all the forms,
they get a bang. The form's recordsource, allowedits and such
are properties, so the get dots.

In real applications, If Microsoft named it, it takes a dot
ahead of it.
If you the developer named it, it takes a bang.

--
Bob Quintal

PA is y I've altered my email address.
Apr 3 '06 #7
bl*******@gmail.com wrote:
Forms!frmMyForm.Visible


This notation is antiquated and inefficient.

The HasModule of a form should be set to true.

All the properties and objects of the form, whether it is open or not,
whether it is a main form or not, can now be referenced with
Form_frmMyForm.Property.
eg.
Form_frmMyForm.Visible will open and show frmMyForm. If frmMyForm is
already open it will ensure that (the default instance of) frmMyForm is
visible.

And multiple instances of a form can be dimmed and intialized with
Dim SomeForms(5) as Form_frmMyForm
For z = 0 to 4
Set SomeForms(z) = New Form_frmMyForm
SomeForms(z).Caption = SomeForms(z).Ca ption & ":" & z
Next z

The bang is an ancient unnecessary ludicrous notation. All objects and
their properties can be referred to with the dot.

It's things like "Forms!frmMyForm.Visible" that make Acess
"programming" a laughing-stock. When we get to referring to subforms
this way people should be rolling on the floor.

(Yes, I know MS recommends it; what further proof do you want?)

I can hear the Cro-Magnons bellowing and pawing right now... they will
arrive soon to defend their archaic turf. They will find or think they
find some syntax error in my code, they will find some case where the
bang is faster, but they're not going anywhere; they're just hanging
on.

Let me respond right now:
Get a fucking life and learn how to program and write code and stop
spewing your stupidity here!
And in case you were wondering, "Yes, I have written more creative and
stable code than you; and for almost all of you, a lot more!"

And now rkc is going to accuse me again of being disrespectful of
people here. Gee, what's a guy going to do?

Apr 4 '06 #8
Lyle Fairfield wrote:
bl*******@gmail.com wrote:
Forms!frmMyForm.Visible


This notation is antiquated and inefficient.

The HasModule of a form should be set to true.

All the properties and objects of the form, whether it is open or not,
whether it is a main form or not, can now be referenced with
Form_frmMyForm.Property.
eg.
Form_frmMyForm.Visible will open and show frmMyForm. If frmMyForm is
already open it will ensure that (the default instance of) frmMyForm is
visible.

And multiple instances of a form can be dimmed and intialized with
Dim SomeForms(5) as Form_frmMyForm
For z = 0 to 4
Set SomeForms(z) = New Form_frmMyForm
SomeForms(z).Caption = SomeForms(z).Ca ption & ":" & z
Next z

The bang is an ancient unnecessary ludicrous notation. All objects and
their properties can be referred to with the dot.

It's things like "Forms!frmMyForm.Visible" that make Acess
"programming" a laughing-stock. When we get to referring to subforms
this way people should be rolling on the floor.

(Yes, I know MS recommends it; what further proof do you want?)

I can hear the Cro-Magnons bellowing and pawing right now... they will
arrive soon to defend their archaic turf. They will find or think they
find some syntax error in my code, they will find some case where the
bang is faster, but they're not going anywhere; they're just hanging
on.

Let me respond right now:
Get a fucking life and learn how to program and write code and stop
spewing your stupidity here!
And in case you were wondering, "Yes, I have written more creative and
stable code than you; and for almost all of you, a lot more!"

And now rkc is going to accuse me again of being disrespectful of
people here. Gee, what's a guy going to do?


"What's a guy going to do?" Any particular reason for not explaining
this without being offensive? Perhaps some of us aren't as well
informed as you, but that doesn't make us Cro-Magnon or stupid.

--
Randy Harris
tech at promail dot com
I'm pretty sure I know everything that I can remember.
Apr 4 '06 #9
rkc <rk*@rochester.yabba.dabba.do.rr.bomb> wrote:
us****@isbd.co.uk wrote:
Well the book "Access 2003" does actually explain it further down the
same chapter - I should have kept reading. However it does seem
backwards to me using syntax like this before explaining it.


What does it say?


There's a section actually entitled - When to Use "!" and "."

It is quite long but gets the essential point across by saying "Use
an exclamation point preceding a name when the name refers to an
object that is *in* the preceding object or collection", then lots of
expansion on this. Then "Use a period preceding a name that refers to
a collection name, a property name or the name of a method ..... use a
period when the following name is *of* the preceding name".

What worries me slightly is that this absolutely fundamental
information is on page 800, to my mind it should be much, much earlier
in the book. It also seems not to be in the Access help at all.

--
Chris Green

Apr 4 '06 #10
bl*******@gmail.com wrote:
Generally, a dot exposes properties and methods and a bang (!) exposes
members of a collection. So forms!frmMyForm.Visible refers to the
visible property of frmMyForm, which is a member of the forms
collection. What makes this harder (or easier, depending on your
perspective) to grasp, is that Access has gotten more and more
forgiving about using the "wrong" notation.

Thanks and, yes, I think Access' forgiving nature is part of the
problem, something (wrong) that works in one context often doesn't
work in another context and this can be the source of endless
confusion.

--
Chris Green

Apr 4 '06 #11
Just to add to the confusion there is yet another notation:

as an alternative to
Forms!frmMyForm.Visible
one can write:
Forms("frmMyForm").Visible
or
Forms("frmMyForm").Form.Requery
or
Forms("aForm").Controls("aControl").FormatConditio ns.FontBold = True

I prefer this style because I find it easier to read. Others may
complain about having to type too many extra characters.

Elsewhere, wherever possible I use the dot notation. The real
advantage this, apart from the autocompletion mentioned by someone else
is that errors are picked up at compile time. Errors (eg misspelled
names) when using ! are only picked at run time.

Jim
bl*******@gmail.com wrote:
Generally, a dot exposes properties and methods and a bang (!) exposes
members of a collection. So forms!frmMyForm.Visible refers to the
visible property of frmMyForm, which is a member of the forms
collection. What makes this harder (or easier, depending on your
perspective) to grasp, is that Access has gotten more and more
forgiving about using the "wrong" notation.


Apr 4 '06 #12
"Lyle Fairfield" <ly***********@aim.com> wrote in message
news:11**********************@v46g2000cwv.googlegr oups.com...
Get a fucking life and learn how to program and write code and stop
spewing your stupidity here!
And in case you were wondering, "Yes, I have written more creative and
stable code than you; and for almost all of you, a lot more!"

And now rkc is going to accuse me again of being disrespectful of
people here. Gee, what's a guy going to do?


Someone needs a hu-ug! :-)

Keith.
Apr 4 '06 #13
rkc
Lyle Fairfield wrote:
And now rkc is going to accuse me again of being disrespectful of
people here. Gee, what's a guy going to do?


Mr. Fairfield, my friend from the north, you are what you are.
You have my respect regardless. That and a 3 dollars Canadian
will get you a cup of coffee with a poofy name.




Apr 4 '06 #14
Jim Devenish <in***************@foobox.com> wrote:
Just to add to the confusion there is yet another notation:

as an alternative to
Forms!frmMyForm.Visible
one can write:
Forms("frmMyForm").Visible
or
Forms("frmMyForm").Form.Requery
or
Forms("aForm").Controls("aControl").FormatConditio ns.FontBold = True

I prefer this style because I find it easier to read. Others may
complain about having to type too many extra characters.

Elsewhere, wherever possible I use the dot notation. The real
advantage this, apart from the autocompletion mentioned by someone else
is that errors are picked up at compile time. Errors (eg misspelled
names) when using ! are only picked at run time.

It also makes slightly more sense to my confused little mind as I can
conceive of a default 'method' of the Forms collection that returns a
named form. Calling this as Forms("frmMyForm") makes sense to my C/Java
mind.

--
Chris Green

Apr 4 '06 #15
Per Lyle Fairfield:
I can hear the Cro-Magnons bellowing and pawing right now... they will
arrive soon to defend their archaic turf. They will find or think they
find some syntax error in my code, they will find some case where the
bang is faster, but they're not going anywhere; they're just hanging
on.


Not me. I'm grateful to know about his.

Thanks.
--
PeteCresswell
Apr 4 '06 #16
Lyle Fairfield wrote:
bl*******@gmail.com wrote:
Forms!frmMyForm.Visible

This notation is antiquated and inefficient.


<snip>

While I certainly don't think any of the respondents so far to Lyle's
post are Cro-Magnon nor anywhere close to any form of primitive man at
any stage other than homo sapiens sapiens, I thought this post was
hilarious.

Unfortunately, I still ascribe to parts of the notation Lyle describes
negatively, but for the most part use dots. I'm not sure why
Forms!myFormName is inefficient, though - does VBA allow
Forms.myFormName? Good heavens, I just checked a nomenclature field on
the hidden values form of an app on my debug window and it does!

?forms.frmv.txtnomworker
Worker

Is this faster or slower or what significnat advantage does it offer
other than providing a cone of silence around me to fend off the
laughter on the floor of non-Access people? 8)

--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me
Apr 4 '06 #17
us****@isbd.co.uk wrote in news:4432597b.0@entanet:
Jim Devenish <in***************@foobox.com> wrote:
Just to add to the confusion there is yet another notation:

as an alternative to
Forms!frmMyForm.Visible
one can write:
Forms("frmMyForm").Visible
or
Forms("frmMyForm").Form.Requery
or
Forms("aForm").Controls("aControl").FormatConditio ns.FontBold =
True

I prefer this style because I find it easier to read. Others may
complain about having to type too many extra characters.

Elsewhere, wherever possible I use the dot notation. The real
advantage this, apart from the autocompletion mentioned by
someone else is that errors are picked up at compile time.
Errors (eg misspelled names) when using ! are only picked at run
time.

It also makes slightly more sense to my confused little mind as I
can conceive of a default 'method' of the Forms collection that
returns a named form. Calling this as Forms("frmMyForm") makes
sense to my C/Java mind.


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).

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Apr 4 '06 #18
"Lyle Fairfield" <ly***********@aim.com> wrote in
news:11**********************@v46g2000cwv.googlegr oups.com:
bl*******@gmail.com wrote:
Forms!frmMyForm.Visible
This notation is antiquated and inefficient.

The HasModule of a form should be set to true.


These are really two completely different issues that are quite
orthogonal to the present discussion.

I have no problem with your very clever suggestion.

I *do* have a problem with using the . for controls and fields on
the form for reasons that I've stated in another post.

[]
I can hear the Cro-Magnons bellowing and pawing right now... they
will arrive soon to defend their archaic turf. They will find or
think they find some syntax error in my code, they will find some
case where the bang is faster, but they're not going anywhere;
they're just hanging on.

Let me respond right now:
Get a fucking life and learn how to program and write code and
stop spewing your stupidity here!
And in case you were wondering, "Yes, I have written more creative
and stable code than you; and for almost all of you, a lot more!"


I don't understand why you have to always make these kinds of
statements in categoricals. There are good and logical reasons for
the use of the ! vs. the . and we disagree on where this judgment
call comes down in the end. I have good reasons for avoiding the .
notation for controls/fields on forms and no one has ever disputed
them, so far as I know.

But I wouldn't object to your suggestion above. It is a very clever
use of the monolithic save model's Access project.

I wonder if it works in Access97?

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Apr 4 '06 #19
"Lyle Fairfield" <ly***********@aim.com> wrote
I can hear the Cro-Magnons bellowing and pawing
right now... they will arrive soon to defend their
archaic turf.


UG like ! cuz look like UG's club. . only look like gob of spit. UG has
spoken.
Apr 4 '06 #20
Larry Linson wrote:
"Lyle Fairfield" <ly***********@aim.com> wrote
> I can hear the Cro-Magnons bellowing and pawing
> right now... they will arrive soon to defend their
> archaic turf.


UG like ! cuz look like UG's club. . only look like gob of spit. UG has
spoken.


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

8)
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me
Apr 4 '06 #21
"Larry Linson" <bo*****@localhost.not> wrote in
news:42AYf.15666$Up2.9230@trnddc07:
"Lyle Fairfield" <ly***********@aim.com> wrote
I can hear the Cro-Magnons bellowing and pawing
right now... they will arrive soon to defend their
archaic turf.


UG like ! cuz look like UG's club. . only look like gob of
spit. UG has spoken.


LOL! UG has spoken wise words.
--
Bob Quintal

PA is y I've altered my email address.
Apr 4 '06 #22
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.

Apr 4 '06 #23
rkc
Lyle Fairfield wrote:

I don't seem to be able to get a form to open using
Form_FormName.Visible (invalid use of property)
or
Form_Form2.Visible = True (nothing happening at all)

The rest of your rant checks out and it's truely
amazing.

Some things you didn't mention.

You can set a recordset to the RecordsetClone
of an unopened form and the data will be there.

You can call an unopened form's user defined Subs
and Functions.

You can access the values of an unopened form's controls
which will be on the first record if the form is bound.

Not sure how any of this is useful. I'm probably to stupid
for that. It was interesting though.

Apr 5 '06 #24
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.

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

Apr 5 '06 #26
rkc
Lyle Fairfield wrote:
A small caveat. When you do those things you mention, you have opened
the form. Probably it is hidden, but it's open.
It may be initialized, but it's not really open. Calling a Public
Sub that issues a docmd.gotorecord raises a form not open error.
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
I'm thinking close it when you're done. I actually ran into a
situation where the form I was messing with was listed twice in
the 'Do you want to save the changes to' dialog. Clicking yes
caused Access to crash-n-burn.
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),
Like if they were declared as static methods in C# or Java.
If you want to use controls on your forms for holding values, you can
enumerate these, much more easily than public class properties.
DW's often wished for auto-magical class properties collection.
Enough! I run off at the mouth too much.


Ya think so?

Apr 5 '06 #27
rkc
Lyle Fairfield wrote:
Form_Form1.Visible = True works for me.
I don't know what would prevent it from working for you.


It's a mystery.

Apr 5 '06 #28
rkc <rk*@rochester.yabba.dabba.do.rr.bomb> wrote in news:tyNYf.40221
$j********@twister.nyroc.rr.com:
Enough! I run off at the mouth too much.


Ya think so?


Well, not if everybody else does for sure; in that case I'll be sure to
think something else!

--
Lyle Fairfield
Apr 5 '06 #29
Per rkc:
It's a mystery.


Have you written some code in the form's module and compiled/saved it yet?

When I tried it, it didn't work the first time. Then I added some code to
the form's module and it did work.
--
PeteCresswell
Apr 5 '06 #30
rkc <rk*@rochester.yabba.dabba.do.rr.bomb> wrote:
Lyle Fairfield wrote:
Form_Form1.Visible = True works for me.
I don't know what would prevent it from working for you.


It's a mystery.

One of the many that causes me problems when trying to program in
Access! :-) (Which is where we came in)

--
Chris Green

Apr 5 '06 #31
Bri

Lyle Fairfield wrote:
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.


AC97 does indeed have the HasModule property. If referred to in VBA, the
Form must be open or you get an error. It seems that only open forms are
part of the Forms collection.

--
Bri

Apr 5 '06 #32
"(PeteCresswell)" <x@y.Invalid> wrote in
news:dd********************************@4ax.com:
Per rkc:
It's a mystery.


Have you written some code in the form's module and compiled/saved it
yet?

When I tried it, it didn't work the first time. Then I added some
code to the form's module and it did work.


I have used this for more than five years exclusively, ie noe Forms
(FormName)!!!!!.....Bullshit. If it won't work, won't compile then there
may be something wrong with your code, objects. Find out what it is,
please. It probably needs fixing regardless.

But, please, don't say it doesn't work. It WORKS!

--
Lyle Fairfield
Apr 5 '06 #33
us****@isbd.co.uk wrote in news:4433b863.0@entanet:
rkc <rk*@rochester.yabba.dabba.do.rr.bomb> wrote:
Lyle Fairfield wrote:
> Form_Form1.Visible = True works for me.
> I don't know what would prevent it from working for you.


It's a mystery.

One of the many that causes me problems when trying to program in
Access! :-) (Which is where we came in)


I know about these many problems. You see, Bill Gates has sent me special
copies of the Access executables and dlls since Access 95 (maybe before).
In these are many short simple methods and properties that work for me
every time (things like Recordset.Collect(0) which is the second fastest
and very simple way to get the value of a recordset field) and work for
almost no one else in the world. You see I post about these things and then
some yahoo responds with "It didn't work!". Now, who knows why it didn't
work? I am so glad I can't see how they made it not work, because, would I
say, "It didn't work because you are incredibly stupid!"? No, never me.

--
Lyle Fairfield
Apr 5 '06 #34
rkc
Lyle Fairfield wrote:
I am so glad I can't see how they made it not work, because, would I
say, "It didn't work because you are incredibly stupid!"? No, never me.


By calling Form_Form2.Visible=True from a command button on another
form.

Lighten up. You're gonna pop a blood vessel.
Apr 5 '06 #35
"Lyle Fairfield" <ly***********@aim.com> wrote in
news:11**********************@g10g2000cwb.googlegr oups.com:
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.
A97 was the first to introduce this property. The goal was to allow
the creation of those "lightweight" forms, which were supposed to be
blazingly fast in comparison to "heavyweight" forms. That was, of
course, ridiculous, as most of the performance drain in a form is
not in the loading of the code module, but in the loading of the
data.
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.


As I said, I expected it not to work in A97, since it did not use
the monolithic Access project. My suspicion is that the reason it
works in A2K is that all the code is in the same object. Even though
you see separate modules, they're all part of the same code project,
and thus interconnected in a way that was not the case in A97.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Apr 5 '06 #36
Lyle Fairfield <ly***********@aim.com> wrote in
news:Xn*********************************@216.221.8 1.119:
us****@isbd.co.uk wrote in news:4433b863.0@entanet:
rkc <rk*@rochester.yabba.dabba.do.rr.bomb> wrote:
Lyle Fairfield wrote:
> Form_Form1.Visible = True works for me.
> I don't know what would prevent it from working for you.

It's a mystery.

One of the many that causes me problems when trying to program in
Access! :-) (Which is where we came in)


I know about these many problems. You see, Bill Gates has sent me
special copies of the Access executables and dlls since Access 95
(maybe before). In these are many short simple methods and
properties that work for me every time (things like
Recordset.Collect(0) which is the second fastest and very simple
way to get the value of a recordset field) and work for almost no
one else in the world. You see I post about these things and then
some yahoo responds with "It didn't work!". Now, who knows why it
didn't work? I am so glad I can't see how they made it not work,
because, would I say, "It didn't work because you are incredibly
stupid!"? No, never me.


Well, it does show that your recommendation does not work in all
cases, but we don't know what it is that's different about the ones
where it doesn't work. Thus, it seems to me like something to be
avoided in general, clever as it may be, since we can't say when it
will actually work properly and when it won't.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Apr 5 '06 #37
Per Lyle Fairfield:
But, please, don't say it doesn't work. It WORKS!


That's what I said - in the end it worked.

--
PeteCresswell
Apr 5 '06 #38
"David W. Fenton" <XX*******@dfenton.com.invalid> wrote in
news:Xn**********************************@127.0.0. 1:
Lyle Fairfield <ly***********@aim.com> wrote in
news:Xn*********************************@216.221.8 1.119:
us****@isbd.co.uk wrote in news:4433b863.0@entanet:
rkc <rk*@rochester.yabba.dabba.do.rr.bomb> wrote:
Lyle Fairfield wrote:
> Form_Form1.Visible = True works for me.
> I don't know what would prevent it from working for you.

It's a mystery.

One of the many that causes me problems when trying to program in
Access! :-) (Which is where we came in)


I know about these many problems. You see, Bill Gates has sent me
special copies of the Access executables and dlls since Access 95
(maybe before). In these are many short simple methods and
properties that work for me every time (things like
Recordset.Collect(0) which is the second fastest and very simple
way to get the value of a recordset field) and work for almost no
one else in the world. You see I post about these things and then
some yahoo responds with "It didn't work!". Now, who knows why it
didn't work? I am so glad I can't see how they made it not work,
because, would I say, "It didn't work because you are incredibly
stupid!"? No, never me.


Well, it does show that your recommendation does not work in all
cases, but we don't know what it is that's different about the ones
where it doesn't work. Thus, it seems to me like something to be
avoided in general, clever as it may be, since we can't say when it
will actually work properly and when it won't.


I can say when it works for me. ALWAYS!

--
Lyle Fairfield
Apr 5 '06 #39
rkc
Lyle Fairfield wrote:
Form_Form1.Visible = True works for me.
I don't know what would prevent it from working for you.


Okey Dokey then. Since I know you are always right I created
a new .mdb file and tried again. The form opened just as
nice as could be. Apparently my testing Lyle's shit .mdb
file is screwed up in some way that caused it not to. It's
odd that everything else about it worked as you said, but
this didn't.

There you have it.
Apr 5 '06 #40
rkc <rk*@rochester.yabba.dabba.do.rr.bomb> wrote in news:AAWYf.36507
$D********@twister.nyroc.rr.com:
Lyle Fairfield wrote:
Form_Form1.Visible = True works for me.
I don't know what would prevent it from working for you.


Okey Dokey then. Since I know you are always right I created
a new .mdb file and tried again. The form opened just as
nice as could be. Apparently my testing Lyle's shit .mdb
file is screwed up in some way that caused it not to. It's
odd that everything else about it worked as you said, but
this didn't.

There you have it.


I rejoice at your success.

--
Lyle Fairfield
Apr 5 '06 #41
rkc
Lyle Fairfield wrote:
I rejoice at your success.


I doubt it.
Apr 5 '06 #42
rkc <rk*@rochester.yabba.dabba.do.rr.bomb> wrote in news:azXYf.16651
$M*******@twister.nyroc.rr.com:
Lyle Fairfield wrote:
I rejoice at your success.


I doubt it.


You are quite wrong.

--
Lyle Fairfield
Apr 5 '06 #43

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

9 posts views Thread by Dynamo | last post: by
2 posts views Thread by Halldór Ísak Gylfason | last post: by
44 posts views Thread by Smokey Grindle | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.