Results 1 to 10 of 10
  1. #1
    Join Date
    May 2012
    Posts
    132

    Unanswered: A necessary unbound text on a form

    How can we make an unbound text in a form, to be required? In other words, the user cannot save and go to next record as long as this unbound field is blank?

  2. #2
    Join Date
    Jun 2005
    Location
    Richmond, Virginia USA
    Posts
    2,763
    Provided Answers: 19
    Just like you would do this, at the Form-level, for a Bound Control, although I cannot imagine why this would ever be necessary!
    Code:
    Private Sub Form_BeforeUpdate(Cancel As Integer)
     If Nz(Me.UnboundField, "") = "" Then
      Cancel = True
      MsgBox "Record Cannot be Saved Until Data is Entered in the Unbound Control!"
      UnboundField.SetFocus
      Exit Sub
     End If
    End Sub
    Linq ;0)>
    Hope this helps!

    The problem with making anything foolproof...is that fools are so darn ingenious!

    All posts/responses based on Access 2003/2007

  3. #3
    Join Date
    May 2012
    Posts
    132
    It worked again, thank you
    I added to the save command button.
    Do you agree with the following code?

    Private Sub Command461_Click()
    If Nz(Me.payment, "") = "" Then
    Cancel = True
    MsgBox "please write the payment type!"
    payment.SetFocus
    Exit Sub
    End If
    DoCmd.GoToRecord , , acNext
    DoCmd.GoToRecord , , acNewRec
    End Sub

    Is it possible that more textboxes to be added to this code? I mean, none of the mentioned text boxes are allowed to be null, otherwise the button cannot record the data and go to the next record.

  4. #4
    Join Date
    May 2012
    Posts
    132
    And the reason i wanted this:
    Order_table keeps data inserted through “salesform” and “giftsform”. The table has a field named amount that keeps the sold amount . If the product is sold it is necessary to write the amount in the form and the corresponding field in the table. But if it is a gift or a sample the amount field will be null.

  5. #5
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    no you are going about this the wrong way
    and whats more your code should be in the forms before update event


    ytou can add waht ever code you require
    you can do any validation you require
    I'd rather be riding on the Tiger 800 or the Norton

  6. #6
    Join Date
    Jun 2005
    Location
    Richmond, Virginia USA
    Posts
    2,763
    Provided Answers: 19
    As healdem said, the code belongs in the Form_BeforeUpdate event, as my posted example showed! Having it elsewhere, such as in your unnecessary "Save" button, would still allow the Record to be saved, with the payment type empty, if the user simply moved to another Record with the native Access navigation buttons, closed the Form, or closed Access itself.

    Linq ;0)>
    Hope this helps!

    The problem with making anything foolproof...is that fools are so darn ingenious!

    All posts/responses based on Access 2003/2007

  7. #7
    Join Date
    May 2012
    Posts
    132
    well, thank you guys, but the code that i coined worked !! however when the form is closed it sitll saves the data

  8. #8
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    yes it works (for a specific case)
    but thats because you haven't put your checking code in the forms before update and stopped the update if the data is invalid

    what you are trying to do is circumvent the default behaviours of Access without any real understanding of what Access does.

    until you have a really really good grounding of how Access works then doing what you are doing is going to be a painful process. you are going to believe you have done XYZ, but because of the way Access works you may also find theat ABC, fgh and so on also work.

    if you are going to add your own methods then you are also going to have to override the the default behaviours as well

    why do you believe you need your own close button, your own save record button and so on, Amongst the many advantages of the Access environment
    is that you can get a working application very quickly.
    its reporting is pretty good
    out of the box its user interface is familiar well understood and well used
    but it does have limitations, especially if you need to have lots of concurrent users

    what you are doing is partially adding your own behaviours to Access but not locking out the default behaviour. if you persists going down your current approach then you will have to code all your forms in the same manner. effectively you are creating work for yourself for the heck of it
    I'd rather be riding on the Tiger 800 or the Norton

  9. #9
    Join Date
    Jun 2005
    Location
    Richmond, Virginia USA
    Posts
    2,763
    Provided Answers: 19
    Quote Originally Posted by ariansman View Post
    ...however when the form is closed it sitll saves the data
    Do you reckon? Which part of

    Quote Originally Posted by Missinglinq View Post

    ...Having it elsewhere... would still allow the Record to be saved, with the payment type empty, if the user... closed the Form, or closed Access itself.
    did you not understand?
    Hope this helps!

    The problem with making anything foolproof...is that fools are so darn ingenious!

    All posts/responses based on Access 2003/2007

  10. #10
    Join Date
    May 2012
    Posts
    132
    i mulled over and now i can understand,
    thank you for your attention,
    i understand that i should obey the basis on which access works uppon. i will attempt to do so.
    i will keep asking,

    thank you for the guides and patience

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •