Ensuring last field changed is saved?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I'm making changes to a program that contains the following comment and code:

Dim ctlActive As Control
' Temporary kludge until all print controls can receive focus (txtPrint
label control
' cannot receive the focus, therefore the last field user enters data
into does not
' otherwise get updated.)
Set ctlActive = ActiveControl
cmdEmail.SetFocus
ctlActive.SetFocus

This is at the top of an OnClick event (attached to a label) that is later
going to do:

DoCmd.RunCommand acCmdSaveRecord
DoCmd.GoToRecord , , acNewRec

My question is the code at the top really needed? Is there some other way to
ensure that all fields updated get saved?

Thanks.
 
I'm making changes to a program that contains the following comment and code:

Dim ctlActive As Control
' Temporary kludge until all print controls can receive focus (txtPrint
label control
' cannot receive the focus, therefore the last field user enters data
into does not
' otherwise get updated.)
Set ctlActive = ActiveControl
cmdEmail.SetFocus
ctlActive.SetFocus

This is at the top of an OnClick event (attached to a label) that is later
going to do:

DoCmd.RunCommand acCmdSaveRecord
DoCmd.GoToRecord , , acNewRec

My question is the code at the top really needed? Is there some other way to
ensure that all fields updated get saved?

Thanks.
Click to expand...

Any changes made in the form are automatically saved as soon as you go
to another (or new) record, so no you don't need to use the
RunCommand line.

You would need to use it if you were going to, for example, print a
report based on the current changed record, if you don't go to the
next record first.
 
I'm making changes to a program that contains the following comment and code:

Dim ctlActive As Control
' Temporary kludge until all print controls can receive focus (txtPrint
label control
' cannot receive the focus, therefore the last field user enters data
into does not
' otherwise get updated.)
Set ctlActive = ActiveControl
cmdEmail.SetFocus
ctlActive.SetFocus

This is at the top of an OnClick event (attached to a label) that is later
going to do:

DoCmd.RunCommand acCmdSaveRecord
DoCmd.GoToRecord , , acNewRec

My question is the code at the top really needed? Is there some other way to
ensure that all fields updated get saved?

Thanks.
Click to expand...

My just sent previous comment referred to your use of
DoCmd.RunCommand acCmdSaveRecord

Upo re-reading your post, I now have no idea if that was your question
or if you meant the stuff above that line.
 
What the code comment appears to be saying is that since the onclick event is
on a label and a label cant get focus (like a command button), the last
modified field wont be updated. This implies that for a field to be updated,
the focus must switch to another control.
I just wondered if this is still true or is it a holdover from prevuious
version.
I'm using Access 2003.
 
What the code comment appears to be saying is that since the
onclick event is on a label and a label cant get focus (like a
command button), the last modified field wont be updated. This
implies that for a field to be updated, the focus must switch
to another control. I just wondered if this is still true or
is it a holdover from prevuious version.
I'm using Access 2003.
Click to expand...
This begs the question of why a label and not a command button?
 
None of this:

Dim ctlActive As Control
' Temporary kludge until all print controls can receive focus (txtPrint
label control
' cannot receive the focus, therefore the last field user enters data into
does not
' otherwise get updated.)
Set ctlActive = ActiveControl
cmdEmail.SetFocus
ctlActive.SetFocus

really makes any sense in this context! As Fred said, any changes made to
any controls on the form will automatically be saved as soon as you go to
another record, which is exactly what

DoCmd.GoToRecord , , acNewRec

does! No control, label or other, has to receive focus for this to happen! My
guess would be that this is some orphan code, code left over that no longer
has a purpose, and probably should have deleted. And to be perfectly frank,
the comments make absolutely no sense, no matter what version of Access they
were originally written in! If they're not causing a problem you can
probably leave them alone. I have to tell you I feel sorry for you,
inheriting soemthing like this!

Good Luck!
 
Back
Top