Probably stupid before update/continuous form question

[aardvick]

I have many forms with imbedded continuous subforms (they look like
datasheets with one line per record). In the parent form I have control
buttons such as "Edit", "Save", "Cancel", etc, with code that changes the
format and edit-ability of fields in the subform.

When the user modifies a record in the subform and then moves to another
record in the same subform, I use the "before update" event to determine if
the user wants to save or discard those changes.

Here is the problem: when a user modifies a record on the continuous subform
and then clicks on my "Save" button (which is on the parent form, remember),
it triggers the "before update" dialog box. Of course. This makes sense as
the user is leaving the record. However it means that the user has to click
"save" twice: once to trigger that they are done and then again on the dialog
box.

The "on click" event for the "Save" button doesn't run until after the
"before update" event for the continuous form. Is there some other event
that I can use to avoid the double save phenomenon?

Sorry if super obvious. No one else seems to have this problem....
-Aardvick

 

[Dennis]

Why not just have the After Update event call the OnClick event directly?

 

[aardvick]

Hi Dennis, Thanks for your response. I don't see how that will solve my
problem, though. By the time the after update event fires, the user has
already has to click twice.

Here is the sequence of events as best I can determine:
- user modifies record in subform
- user clicks "save" button on parent form
- before update event of the subform fires, opens dialog box
- user clicks "save" button on dialog box
- on click event of "save" button on dialog box button fires
- dialog box closes
- after update event of subform fires
- on click event of "save" button on parent form fires


What I want is for the second step above (user clicks "save" on parent form)
to somehow cancel the before update code (why ask if they want to save - they
just clicked save, duh!)

I tried using the PreviousControl property, but it returned the field that
was modified, not the button click that triggered the update event.

Bleahhhhh...

 

[Marshall Barton]

I have many forms with imbedded continuous subforms (they look like
datasheets with one line per record). In the parent form I have control
buttons such as "Edit", "Save", "Cancel", etc, with code that changes the
format and edit-ability of fields in the subform.

When the user modifies a record in the subform and then moves to another
record in the same subform, I use the "before update" event to determine if
the user wants to save or discard those changes.

Here is the problem: when a user modifies a record on the continuous subform
and then clicks on my "Save" button (which is on the parent form, remember),
it triggers the "before update" dialog box. Of course. This makes sense as
the user is leaving the record. However it means that the user has to click
"save" twice: once to trigger that they are done and then again on the dialog
box.

The "on click" event for the "Save" button doesn't run until after the
"before update" event for the continuous form. Is there some other event
that I can use to avoid the double save phenomenon?

Most people do not worry about "Edit", "Save", "Cancel"
things and just let the user do what they need without all
those buttons and consequently without the problems you are
having.

That said, the next easiest thing you can do is to put the
buttons in the subform's footer (or header) section.

To have the buttons on the main form control actions in the
subforms is rather messy invovling some ugly code in both
forms. I strongly recommend against this approach.

 

[aardvick]

Marshall,
One reason for having "all those buttons" is because the form is read only.
I prefer data to be read-only until a user intends to edit it. What method
do you use to allow a user to switch from read-only to editable?

Putting the control buttons on the footer of the subform turns out to be a
reasonable compromise. It allows me to use Screen.ActiveControl in the
"before update" code to determine if the dialog box should appear or not.
I.e. If the user clicks the "Save" button, the dialog box is not triggered;
if they move to a new record, however, it is. This was not possible when the
controls were in parent form.

Thanks for your help!
-Aardvick

 

[Marshall Barton]

One reason for having "all those buttons" is because the form is read only.
I prefer data to be read-only until a user intends to edit it. What method
do you use to allow a user to switch from read-only to editable?

Putting the control buttons on the footer of the subform turns out to be a
reasonable compromise. It allows me to use Screen.ActiveControl in the
"before update" code to determine if the dialog box should appear or not.
I.e. If the user clicks the "Save" button, the dialog box is not triggered;
if they move to a new record, however, it is. This was not possible when the
controls were in parent form.

The only question I see here is "What method do you use
....?"

I use the Locked property on the data controls that users
are not allowed to edit. I set the control's Tag property
to something like LOCK to identify the specific controls.
Then I use a Sub procedure like:

Private Sub SetLocks(OnOff As Boolean)
Dim ctl As Control
For Each ctl In Me.Controls
If ctl.Tag = "Lock" Then ctl.Loacked = OnOff
Next ctl
End Sub

Then the Form's Current event would use:
SetLocks True

And you Edit button's Click event would use:
SetLocks False