Re: Suspend form close

Tech-Archive recommends: Fix windows errors by optimizing your registry

Thanks again for all of your help, and for the validation code you provided.
I have copied this posting, and will study it in more detail over time. I
think I see the general idea of passing a field list to the called procedure,
and the result back to the original event. I like the highlighting feature.
I am dealing mostly with people who are highly proficient in their areas of
expertise, but applications such as this are not among those areas. My
approach to databases, especially ones that some people will use only rarely,
is that training shouldn't involve much more than showing them where the
program is located. Even if they are trained, they probably won't remember
three months later what they learned about the program (nor would I really
expect them to), so it needs to be as self-explanatory as I can make it.
Thank you too for your explanation of Cancel = True. As I understand it, if
an event's code gets to that line it is almost as if the code never ran,
except that I will have seen message boxes and other things that occurred
before that line. If Before Update is cancelled, the update (save) does not
occur.
OpenArgs is my next project. I will investigate and experiment. That
should keep me busy for a while (along with the rest of my job). I really
appreciate the time, expertise, and detail you have put into your replies.

"Graham Mandeno" wrote:

> Hi Bruce
>
> "BruceM" <BruceM@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
> news:23736BED-6C9E-48AD-84C5-606D7945646D@xxxxxxxxxxxxxxxx
> > Thanks so much for all of your help. Regarding validation, all of the
> > fields
> > on the Recommendation tab need to be completed before the record is saved.
> > In other words, it's all of the fields or none of them in a section. To
> > validate the next section (Response) I use:
> > If Not IsNull(Me.txtResponse) And IsNull(Me.cboResponseName) Then
> > (validation code)
> > End If
>
> OK - then it may not be necessary to "tell" the form which phase is being
> completed. However, you might find it's easer to use OpenArgs to do so.
>
> > If any of the text boxes in Recommendation contains a value the others are
> > tested, otherwise the code passes to the next step. As it stands the
> > record
> > could contain a value for name or date but nothing for the actual
> > response,
> > but that is very unlikely. I can add something if that ever turns out to
> > be
> > a problem.
> > I have heard of OpenArgs, but I don't think I have used it. I will have
> > to
> > investigate further. I have used class modules only when they have been
> > part
> > of code provided by others. Another item on my list of things about which
> > I
> > need to know more.
>
> Oh yeah - there's always plenty of those :-)
>
> A form's class module is simply a fancy name for the code module attached to
> a form. The reason it's a *class* module is that the code is only
> instantiated when the class object (the form) exists (is open).
>
> > I would rather validate at the form level, and undo if needed. I will
> > admit
> > I am not that familiar with table level validation. It works well enough
> > from what I have seen, but the error messages aren't all that helpful.
> > Also,
> > table level validation would be difficult (I think) with the record being
> > added to in stages.
>
> Table level vaidation will NOT work here. You cannot have "required" fields
> which are not requred... *just yet*.
>
> > The thing I need to accomplish with validation is to prevent the user from
> > saving an incomplete section. Users must not have that option.
> > In the code snippet you suggested for the e-mail:
> >
> >> If Me.Dirty Then Me.Dirty = False
> >> ' code will not get here if record validation fails
> >> DoCmd.SendObject ...
> >
> > I take it that this would be placed after the attempt to save the record.
> > My partial understanding of "If Me.Dirty Then Me.Dirty = False" is:
> > "If the record has been changed (Dirty) then...", but I still can't get my
> > mind around what Me.Dirty = False means. For that matter, I'm not sure I
> > have the first part correct.
>
> I should have explained... it's a bit arcane, but Me.Dirty = False is simply
> one way to save a record. If BeforeUpdate is cancelled, then it will fail
> with an error, so execution will pass to the error handling section and the
> next line of code will not be executed.
>
> > My point about the called procedure is that I want the form's Before
> > Update
> > event to say:
> > "If this text box is null but shouldn't be, then generate an error message
> > (MsgBox vbOKCancel). If the choice is "OK", undo the changes and exit.
> > If
> > the choice is Cancel, go back to the form to fill in the missing
> > information."
> > As it stands, I am calling the message box procedure from within Before
> > Update, which means (I think) that I can't undo from within the called
> > procedure. I can only undo from within Before Update (or from another
> > Event), unless there is a reasonable way to pass the choice (OK or Cancel)
> > from the called procedure back to Before Update. Even if I can do that,
> > it
> > is probably just as well to keep the message box (and the resultant choice
> > between OK and Cancel) within Before Update. That is my best guess based
> > on
> > my possibly incomplete understanding.
>
> Here is a function I use routinely to check for required fields:
>
> Public Function fm_CheckRequiredFields(f As Form, FieldList As Variant, _
> Optional NormalColour As Long = vbWhite, _
> Optional HighlightColour As Long = &H60FFFF) As Integer
> Dim iFirstTab As Integer, sFirstTab As String
> Dim c As Control, i As Integer, iBadFields As Integer
> For i = LBound(FieldList) To UBound(FieldList)
> Set c = f.Controls(FieldList(i))
> If IsNull(c) Then
> If iBadFields = 0 Or c.TabIndex < iFirstTab Then
> iFirstTab = c.TabIndex
> sFirstTab = c.Name
> End If
> iBadFields = iBadFields + 1
> c.BackColor = HighlightColour
> Else
> c.BackColor = NormalColour
> End If
> Next
> If iBadFields Then
> f.Controls(sFirstTab).SetFocus
> fm_CheckRequiredFields = iBadFields
> End If
> End Function
>
> You pass it the current form object (Me) and an array of control names. It
> checks each of the controls for null. If a control is OK (not null) it sets
> its BackColor to NormalColour (default white), otherwise it sets it to
> HighlightColour (default pale yellow). It sets focus to the first (if any)
> of the invalid (null) controls according to the tab order of the form, and
> then returns the number of invalid controls.
>
> So, you can say something like this:
> Select Case Me.Openargs
> case 1 ' recommendation
> Cancel = fm_CheckRequiredFields( Me, _
> Array( "Field1", "Field2", "Field3")
> case 2 ' response
> Cancel = fm_CheckRequiredFields( Me, _
> Array( "Field4", "Field5", "Field6")
> ... etc
> End Select
> If Cancel then
> If msgbox( "Input is required in the highlighted fields. Click OK
> to fix " _
> & "this, or Cancel to undo all your changes and close the
> form", _
> vbOkCancel ) = vbCancel Then
> Cancel = false
> Me.Undo
> DoCmd.Close acForm, Me.name
> End If
> End If
>
> > Again, thanks for your help. If I could trouble you just a bit further
> > (and
> > ask for your patience with what may be denseness on my part), the thing
> > about
> > Cancel = True (or False) that I don't understand is the Cancel part. What
> > is
> > Cancel = True saying? What is being cancelled?
>
> Cancel is an argument provided for the event procedure (EP) of most of the
> events that can be cancelled. Setting Cancel to a non-zero value will cause
> that event to be cancelled when the EP exits.
>
> So, Cancel=True in Form_BeforeUpdate causes the form's Beforeupdate event to
> be cancelled (which prevents the update occurring). Similarly, Cancel=999
> in Form_Unload cancels the form's Unload event, which prevents the form
> closing. There are many other events which can be cancelled.
>
> --
> Good Luck!
>
> Graham Mandeno [Access MVP]
> Auckland, New Zealand
>
>
>
.

Relevant Pages

  • Prevent a record being saved after an error occurs
    ... "cmdSaveRecord" sub which, amongst other things, executes this command: ... Within here, some validation is ... If the control fails ... Cancel = True ...
    (microsoft.public.access.formscoding)
  • Re: Please help : Click event not raised when clicking button!!!
    ... When cancel the vaidation the activecontrol is set by the ... The> CausesValidation property of the Close button is set to False; textbox> validation is fired using the Validate method (I know this seems a bit ... > Private Sub Form1_ClosingHandles MyBase.Closing ...
    (microsoft.public.dotnet.framework.windowsforms)
  • Re: Validation for empty fields not working for 3 of 7 controls
    ... John: Thanks so much for the instructive advice. ... And the Cancel = True cancels the ... >>Enter and On Dirty events of a text box control. ... if you're doing validation, the AfterUpdate ...
    (microsoft.public.access.formscoding)
  • Re: Suspend form close
    ... Regarding validation, all of the ... > from what I have seen, but the error messages aren't all that helpful. ... unless there is a reasonable way to pass the choice (OK or Cancel) ... You pass it the current form object and an array of control names. ...
    (microsoft.public.access.formscoding)
  • Re: validate date, using calendar
    ... what I do is to put all those validation checks into the BeforeUpdate ... Dim bWarn as Boolean ... Cancel = True ... How can I have the calendar picker itself do the validating? ...
    (microsoft.public.access.formscoding)