Form Design Question (1 Viewer)

[tmyers]

Kind of a general / best practice question.

I have a form that is used to create "containers" for items (think a box that has many items in it) and currently there is a sub-form that the user can utilize to populate said container with items (linked vis master/child). My question is this, I was wanting to have the sub-form locked and disabled by default but when the user wants to populate it, they would click a button that would enable and unlock the sub-form and set focus to it then when they leave said sub-form and set focus elsewhere, the form would go back to being locked and disabled to prevent accidental editing of its contents. I tried doing it as a pop up, but for some reason have issues with getting the required ID's passed into it without having the ability to set master/child fields.

Is this a good way to handle it? I have controlled forms like this in the past, but have become curious if that is a good way to manage data entry.

 

[plog]

I would say no, as a user it would make me mad. If I want to add/edit a record, just let me add/edit a record without extra button clicks.

If you still want this locked function, I would simply make it a regular subform on the main form and have that button enable/disable the subform when clicked. Using a seperate popup form adds unnecessary complexity.

 

[tmyers]

Maybe I am making it overly complex for no reason then. I will just leave it enabled and as is and trust that the user(s) wont be dumb and accidentally edit a record they didn't meant to.

 

[LarryE]

If you want to enable or disable the sub-form:

1. In the main forms OnLoad event use Me.SubFormName.Enable=False
2. Create a command button on the main form and in the OnClick event use Me.SubFormName.Enable=True

I don't consider this to be a "best practice" question. I have enabled and disabled subforms for many reasons. Do what you think is best for your situation.

 

[The_Doc_Man]

trust that the user(s) wont be dumb and accidentally edit a record they didn't meant to.

Ah, now THERE is the difficult part. Users are often dumber than a box of rocks and will do things you could not understand, either as to effect or as to motive.

Your idea of having a toggle button to enable or disable updates is not nearly so annoying as a pop-up would be. I will not tell you how to do what you want to do because you know your environment and I don't. But know this: It is a tough battle to find the balance between protecting your data and annoying the users to the point that they deem the form unusable. The protection vs convenience factor is not black-and-white but is a continuous sliding gray scale. I feel your pain. Be prepared to adjust your solution more than once to try to find that balance. Perhaps you should consider this comment as a word of both encouragement and commiseration.

 

[tmyers]

My main concern is the user having the wrong "container" selected and entering information to it then the material becoming "lost" requiring time researching where it was likely entered in error at. I figured having the subform disabled until they click the button which would ensure that the material is entered under the correct ID and would prevent this from happening at least 95% of the time, but as you all have said, it adds an extra click which could also be considered an annoyance. I know it wouldn't be fool proof, as just like Doc said, users can be dumber than a box of rocks and find a way to mess anything up.

 

[The_Doc_Man]

This is where Murphy's law, 2nd half, becomes important. Ed Murphy's famous law is always half-forgotten. He said "Anything that CAN go wrong WILL go wrong." What people forget is the next part - "... therefore, build so that it can't go wrong." Which explains molded plugs in computers that cannot be plugged in upside down or sideways. They have one and only one orientation.

You trick in this context is to try to tell from the information at hand whether the person is entering data to the wrong container. If, for example, your situation is that only one person should ever be loading a container at a time, to find a way to lock the container to others. But if it is a shared free-for-all of entering data, you might have to devise some other method of verifying that a person has the right container. I don't know what you have there, but the method invariably requires that you provide the user with enough info that they might recognize their mistake sooner rather than later. AND if you have too high a rate of load errors, perhaps keeping a log of who was entering loads to box X might be useful in a group meeting or private session to say something like, "Hey, Joe - you entered nine loads incorrectly into container XX last week and it took us a while to find them." If people know you are watching, they tend to be at least SLIGHTLY more careful.

This log file idea doesn't have to be huge or a long-term tattle-tale facility. You can purge it as often as you need. But just introduce a very small amount of "big brother is watching" paranoia and your users might be better motivated to be more careful. This is just an idea off the top of my head. It's slick, though. (My head, not necessarily the idea...)

 

[jdraw]

@tmyers,

You may want to consider adding an audit trail to your project/processing. That is to record for each Add/Modify/Delete who did the change, what was changed ,when it was changed (timestamp). I suggest this if, as you pointed out, users "often" adjust/add an unintended record. Asking the user to confirm his intended action before committing the change may be sufficient. As Doc said-- you know your environment, users, expectations and criticality of unintended edits.

 

[Pat Hartman]

At some point you have to trust the user. Even the unlock/lock solution assumes the user KNOWS he's on the right container. One thing you should always do when working with a subform is to protect the user from trying to enter a row in the subform when the main form isn't positioned on a record. That solution is to add code to the subform's BeforeInsert event. Here's an example from one of my forms.

Private Sub Form_BeforeInsert(Cancel As Integer)
    If IsNull(Me.Parent!StateID) Then
        MsgBox "Please add a State before entering a City.", vbOKOnly
        Cancel = True
        Me.Undo
        Me.Parent!StateAbbr.SetFocus
        Exit Sub
    End If
End Sub

Then of course, your bottom line of defense is the form's BeforeUpdate event where you validate data. Here is another example. The first If calls a function that ensures all required fields are not null. Then further validation continues below. To use the EditRequired function in your own app, just place "Required" in the Tag property of any control that you want validated. passing in (Me) gives the function a reference to a form or subform and that makes the code universal. You can use it without change on any and all forms

The final part of the BeforeUpdate event is logging the date/time and the user who did the update. This is not a change log but it gives you a way of identifying who made the last change and when. I use this on most tables. It is mostly for my use if I have to debug a problem and I rarely show the two fields on any forms since the user doesn't actually ever interact with the fields. The app populates them silently as each record is saved.

Private Sub Form_BeforeUpdate(Cancel As Integer)
    If EditRequired(Me) = "Error" Then      ' check required fields
        Cancel = True
        Exit Sub
    End If
  
    If Me.Population & "" = "" Then
    Else
        If IsNumeric(Me.Population) Then
            If Me.Population < 0 Then
                MsgBox "Population must be a positive number", vbOKOnly
                Cancel = True
                Me.Population.SetFocus
                Exit Sub
            End If
        Else
            MsgBox "Population must be numeric.", vbOKOnly
            Cancel = True
            Me.Population.SetFocus
            Exit Sub
        End If
    End If
          
  
    Me.UpdateBy = Environ("UserName")
    Me.UpdateDT = Now()
End Sub

Public Function EditRequired(frm As Form) As String
    Dim ctl As Control
  
    EditRequired = "Valid"
  
    For Each ctl In frm.Controls
    Select Case ctl.ControlType
        Case acTextBox, acComboBox, acListBox, acCheckBox, acOptionGroup
            If InStr(ctl.Tag, "Required") Then
                    If ctl.Value & "" = "" Then
                        MsgBox ctl.Name & " -- is required."
                        ctl.SetFocus
                        EditRequired = "Error"
                        Exit Function
                    End If
            End If
    End Select
Next ctl
Set ctl = Nothing
End Function

 

[Pat Hartman]

Thanks for the like but it is more helpful to people who find this thread if you actually use your words to indicate which suggestion is the one you went with.

 

[tmyers]

I know, I apologize as my afternoon got really busy and my mind is scattered.
Your method is what I will go with as I had already started working that direction with using validation rather then just shutting off the control as I wanted to try something new and learn in the process. I also feel users would have a better experience with this rather than the control simply being shutoff as I had previously done.

 

[Pat Hartman]

Thanks