Is it generally considered good practice to ...

[MLH]

I have frmMainMenu with the following two code
lines invoked on a button click...

2420 DoCmd.OpenForm "frmVehicleEntr yForm", A_NORMAL, , , A_ADD,
A_NORMAL
2440 DoCmd.GoToRecor d , , A_NEWREC

Is it generally considered good practice to issue the command
in line #2440 - intended to go to a new record in the vehicle entry
form - from frmMainMenu?

BTW, frmVehicleEntry Form's AllowEdits, AllowDeletions, AllowAdditions
and DataEntry property settings are all Yes. Does line #2440 even need
to be executed?

[Larry Linson]

"MLH" <CR**@NorthStat e.netwrote

>I have frmMainMenu with the following two code
lines invoked on a button click...

2420 DoCmd.OpenForm "frmVehicleEntr yForm", A_NORMAL, , , A_ADD,
A_NORMAL
2440 DoCmd.GoToRecor d , , A_NEWREC

Is it generally considered good practice to issue the command
in line #2440 - intended to go to a new record in the vehicle entry
form - from frmMainMenu?

You have specified in the OpenForm that it is to be opened in DataEntry mode
with the "A_ADD", which will override the actual Form properties, so there
is no need. In my not-so-humble opinion, redundant code is not "good
practice" unless it is _necessary_ to understanding for someone reading the
code, later.

However, code will continue to be executed, and, in my experience, the
OpenForm will have been completed, so that the GoToRecord will apply to the
newly opened form which will be the active form (that is, the one with the
Focus), even if you have not specified opening in Data Entry mode. You are
relying on the newly opened Form being the active Form, but that is the case
with the code you show, and will continue to be the case barring some design
change to Access itself.

All that said, the constants you are using are from Access 1.0 - Access 2.0
days, but the format of the DoCmd.OpenForm is of more recent vintage (in
Access 2.0, it would be DoCmd OpenForm...). But just in case, you _were_
asking about Access 2.0, I do not have that version readily available to
test, but think the answers are the same.

And, as an aside, for anyone asking about a version as far from being
current as Access 2.0 now is, it is a Really Good Idea to mention the
version. In fact, given all the "dramatic" changes in Access 2007, it is
probably more important than ever to identify the version that you are
using.

BTW, frmVehicleEntry Form's AllowEdits,
AllowDeletions, AllowAdditions and DataEntry
property settings are all Yes. Does line #2440
even need to be executed?

No, it does not, as discussed above.

Larry Linson
Microsoft Access MVP

[MLH]

On Tue, 08 May 2007 17:25:16 GMT, "Larry Linson"
<bo*****@localh ost.notwrote:

>"MLH" <CR**@NorthStat e.netwrote

>>I have frmMainMenu with the following two code
lines invoked on a button click...

2420 DoCmd.OpenForm "frmVehicleEntr yForm", A_NORMAL, , , A_ADD,
A_NORMAL
2440 DoCmd.GoToRecor d , , A_NEWREC

Is it generally considered good practice to issue the command
in line #2440 - intended to go to a new record in the vehicle entry
form - from frmMainMenu?

You have specified in the OpenForm that it is to be opened in DataEntry mode
with the "A_ADD", which will override the actual Form properties, so there
is no need. In my not-so-humble opinion, redundant code is not "good
practice" unless it is _necessary_ to understanding for someone reading the
code, later.

Thank-you.

>
However, code will continue to be executed, and, in my experience, the
OpenForm will have been completed, so that the GoToRecord will apply to the
newly opened form which will be the active form (that is, the one with the
Focus), even if you have not specified opening in Data Entry mode. You are
relying on the newly opened Form being the active Form, but that is the case
with the code you show, and will continue to be the case barring some design
change to Access itself.

Thx for that. 'tis reassuring to know that's the case.

>
All that said, the constants you are using are from Access 1.0 - Access 2.0
days, but the format of the DoCmd.OpenForm is of more recent vintage (in
Access 2.0, it would be DoCmd OpenForm...). But just in case, you _were_
asking about Access 2.0, I do not have that version readily available to
test, but think the answers are the same.

I agree with you on that. I've been getting by on a bit of luck.
?a_add
0
?acFormAdd
0
?acnormal
0
?a_normal
0
Where it gets unlucky is when I post code here with the old 1.0 and
2.0 constants in it. It can lend confusion to my question. Thx 4 the
'heads up' on that topic. Do you think I could go wrong with a global
search 'n replace in forms & modules substituting acFormAdd for A_Add?

>
And, as an aside, for anyone asking about a version as far from being
current as Access 2.0 now is, it is a Really Good Idea to mention the
version. In fact, given all the "dramatic" changes in Access 2007, it is
probably more important than ever to identify the version that you are
using.

Absolutely. I failed to mention that I was working in A97. And using
1.0 / 2.0 references therein - well, that was just more crumming icing
on the cake.

>

BTW, frmVehicleEntry Form's AllowEdits,
AllowDeletions, AllowAdditions and DataEntry
property settings are all Yes. Does line #2440
even need to be executed?

No, it does not, as discussed above.

Larry Linson
Microsoft Access MVP

[Tim Marshall]

Larry Linson wrote:

All that said, the constants you are using are from Access 1.0 - Access 2.0
days, but the format of the DoCmd.OpenForm is of more recent vintage (in
Access 2.0, it would be DoCmd OpenForm...).

Does the guy even realize that intellisense will prompt you for the
correct constants?
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Be Careful, Big Bird!" - Ditto "TIM-MAY!!" - Me

[Larry Linson]

"MLH" <CR**@NorthStat e.netwrote

. . . Do you think I could go wrong with a global
search 'n replace in forms & modules substituting
acFormAdd for A_Add?

To me, the meanings are obvious, even with the Access 2.0 constants. I
probably wouldn't bother to change them, as long as Access supports them for
backward compatibility.

I'd certainly use the current constants when I write a new statement, and,
as Tim Marshall pointed out, Intellisense will show you the options. But, of
course, you don't get that "assistance " when you convert older code to the
current version, as you apparently did from Access 2.0 to Access 97.

And, yes, if you use a mixture of old and new formats, there are some who
might complain about "consistenc y", but, as long as it doesn't affect the
readability of the code, I wouldn't worry.

Larry Linson
Microsoft Access MVP

>>And, as an aside, for anyone asking about a version as far from being
current as Access 2.0 now is, it is a Really Good Idea to mention the
version. In fact, given all the "dramatic" changes in Access 2007, it is
probably more important than ever to identify the version that you are
using.

Absolutely. I failed to mention that I was working in A97. And using
1.0 / 2.0 references therein - well, that was just more crumming icing
on the cake.

>>

BTW, frmVehicleEntry Form's AllowEdits,
AllowDeletions, AllowAdditions and DataEntry
property settings are all Yes. Does line #2440
even need to be executed?

No, it does not, as discussed above.

Larry Linson
Microsoft Access MVP

[MLH]

All good suggestions. Thanks.

>
To me, the meanings are obvious, even with the Access 2.0 constants. I
probably wouldn't bother to change them, as long as Access supports them for
backward compatibility.

I'd certainly use the current constants when I write a new statement, and,
as Tim Marshall pointed out, Intellisense will show you the options. But, of
course, you don't get that "assistance " when you convert older code to the
current version, as you apparently did from Access 2.0 to Access 97.

And, yes, if you use a mixture of old and new formats, there are some who
might complain about "consistenc y", but, as long as it doesn't affect the
readability of the code, I wouldn't worry.

[MLH]

Yep, the guy realizes that. But the guy
doesn't always follow good advice because
he's a stubborn old fart insistent on learning
things the hard way. (sorry)