BeforeUpdate or AfterUpdate ?

Hi all,

I have an unbound form in which I have (amongst others) two comboboxes with 
mandatory data.

Although I present a combobox, limited to the choices to pick out, people 
manage not to fill in those data and to jump via the TAB-key to the next 
field.  Of course I’ll have NULL value for this combobox, but how can I force 
the user to look for the correct row ?

In the BeforeUpdate or in the AfterUpdate event ?

I have some code like :

Private Sub CboAfterUpdate()
if isnull(me.Cbo) then
		Beep
		Msgbox(“You must choose a value”)
		Me.cboAfter.setfocus
endif
end sub

But this does not seem to be helpful and it does not prevent the user to 
jump to the next TAB-stop.

Any help will be appreciated.

Thank you, 

W

0
Utf
1/6/2008 11:35:00 PM
access.formscoding 7493 articles. 0 followers. Follow

11 Replies
1126 Views

Similar Articles

[PageSpeed] 28

W wrote:
>I have an unbound form in which I have (amongst others) two comboboxes with 
>mandatory data.
>
>Although I present a combobox, limited to the choices to pick out, people 
>manage not to fill in those data and to jump via the TAB-key to the next 
>field.  Of course I�ll have NULL value for this combobox, but how can I force 
>the user to look for the correct row ?
>
>In the BeforeUpdate or in the AfterUpdate event ?
>
>I have some code like :
>
>Private Sub CboAfterUpdate()
>if isnull(me.Cbo) then
>		Beep
>		Msgbox(�You must choose a value�)
>		Me.cboAfter.setfocus
>endif
>end sub
>
>But this does not seem to be helpful and it does not prevent the user to 
>jump to the next TAB-stop.


Generally, it's better to use the form's BeforeUpdate event,
because users can click anywhere and never touch the combo
box (i.e. none of its event will be invoked).

-- 
Marsh
MVP [MS Access]
0
Marshall
1/7/2008 12:12:56 AM
On Sun, 6 Jan 2008 15:35:00 -0800, W <W@discussions.microsoft.com> wrote:

>In the BeforeUpdate or in the AfterUpdate event ?

Since the Form is unbound, its before and after update events will never fire;
and since the user might simply never setfocus to the controls, their before
and afterupdate events will never fire either.

You'll need to use whatever event (a button click perhaps?) you have
programmed to write the data to the table.

That's just one of the costs of using unbound forms: you must manually do what
Access does automatically with bound forms.

             John W. Vinson [MVP]
0
John
1/7/2008 1:07:20 AM
You don't need to use setfocus.

Simply use the combo boxes before update event, and set the cancel flag to 
true.

in fact a significant difference between the before update event, and the 
after update event, is that the before update event can be canceled.

eg:

if isnull(me.Cbo) then
   Beep
   Msgbox("You must choose a value")
   cancel = true
end if

if you do the above setting cancel=true old will prevent the cursor and the 
user leaving the control, and you'll not have to set focus.


-- 
Albert D. Kallal    (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal@msn.com


0
Albert
1/7/2008 1:29:58 AM
Sheesh, I missed the unbound issue.  Good thing you jumped
in John.
--
Marsh


John W. Vinson wrote:

>On Sun, 6 Jan 2008 15:35:00 -0800, W <W@discussions.microsoft.com> wrote:
>
>>In the BeforeUpdate or in the AfterUpdate event ?
>
>Since the Form is unbound, its before and after update events will never fire;
>and since the user might simply never setfocus to the controls, their before
>and afterupdate events will never fire either.
>
>You'll need to use whatever event (a button click perhaps?) you have
>programmed to write the data to the table.
>
>That's just one of the costs of using unbound forms: you must manually do what
>Access does automatically with bound forms.
>
>             John W. Vinson [MVP]

0
Marshall
1/7/2008 2:21:01 AM
Albert D. Kallal wrote:
>You don't need to use setfocus.
>
>Simply use the combo boxes before update event, and set the cancel flag to 
>true.
>
>if isnull(me.Cbo) then
>   Beep
>   Msgbox("You must choose a value")
>   cancel = true
>end if

And how does this help if the user

Doesn't enter the Combobox  at all

or 

Enters the combobox but doesn't select a value, merely Yabs to the next
control?

The cbo's BeforeUpdate will only fire IF a selection is made.

-- 
There's ALWAYS more than one way to skin a cat!

Answers/posts based on Access 2000/2003

Message posted via http://www.accessmonster.com

0
Linq
1/7/2008 6:27:38 AM
Hi mr Vinson and all the other good man and one lady,

You all put me back into reality.
Many thanks for your answers.  As a matter of fact, having studied yesterday 
the Q&A's on this site, I found the answer.

Where can I find GOOD documentation about all the events one can meet in an 
form ?

Eventually, I programmed the OnEnter event of my Save button to verify if 
all data have been put in the places and the format I want them to be.

Thanks again,

W

"John W. Vinson" wrote:

> On Sun, 6 Jan 2008 15:35:00 -0800, W <W@discussions.microsoft.com> wrote:
> 
> >In the BeforeUpdate or in the AfterUpdate event ?
> 
> Since the Form is unbound, its before and after update events will never fire;
> and since the user might simply never setfocus to the controls, their before
> and afterupdate events will never fire either.
> 
> You'll need to use whatever event (a button click perhaps?) you have
> programmed to write the data to the table.
> 
> That's just one of the costs of using unbound forms: you must manually do what
> Access does automatically with bound forms.
> 
>              John W. Vinson [MVP]
> 
0
Utf
1/7/2008 7:28:02 AM
"Linq Adams via AccessMonster.com" <u28780@uwe> wrote in message 
news:7dd709939a2f2@uwe...

>
> And how does this help if the user
>
> Doesn't enter the Combobox  at all
>
> or
>
> Enters the combobox but doesn't select a value, merely Yabs to the next
> control?

Remember, the user asked WHAT event (before, or after update) of the combo 
box to use. I think is VERY clear that the before update event is the clear 
winner.  We were only given two choices by the user.

Of course I assume that most people here will also assume that in addition 
to the above testing of the controls, there has to be some code that 
eventually writes out, or uses this data (and tests that data before hand). 
However we do want to give the user warning at the time when he uses the 
combo box, but we WILL STILL need additional code if the control(s) NEVER 
receive the focus.

Thus, I am of course assuming that the user Obviously realizes that 
additional code at update time (or examine time) will be required. In fact I 
don't know of any access developer that assumes that you can just use any 
event on a control to verify the final data before writing out. We've never 
EVER had that ability anyway. You either use data engine integrity or you 
put in your own special code that test things and use your own custom 
messages.

Furthermore we don't know if the users actually updating data, and with the 
given information given we actually can NOT make that assumption.

The only thing we have at this point in time is which of the two events to 
use, and clearly in my humble opinion of the before update event is the 
correct event to use. We *could* use lost focus, but then again, why? We are 
back to square one if the control NEVER receives the focus!!!

So, in addition to using the before update event,  if the control never 
receives the focus, and the control is never modified, then I have to assume 
that most people here have concluded that additional code WILL be needed 
when the data needs to be used.

So perhaps I'm assuming too much here. Perhaps the obvious conclusion that 
additional checking code will be needed at update, or at the time when the 
data used perhaps was too much of an obvious conclusion on my part (but in 
effect we've always had to do it that way).

So, yes....if I was coding this, I would use

1) the before update event of the control
and,
2) Additionally I would also have code at update (or examine time) that 
tests the data. (so, fair question on your part).

Of course the person could use the lost focus event, but as we mentioned if 
the control never gets the focus, then we still need the code at 
update/examine time. Furthermore the lost focus event does not have a cancel 
event, and I know that experienced developers will instinctively and 
naturally look to the before update event for the controls validation code.

There might be a VERY small UI advantage to using the lost focus event, I 
think this advantage does not out weigh the fact that every developer is by 
natural instinct to look and find the verification code for that control in 
the before udpate event. That's where verification code traditionally goes.

The above approach is pretty much par for the course, and a lot of my forms 
do have the testing code in the before update event of a contorl, and ALSO 
that of the form's before update event (or this case an unbound form, when 
the data is to be used).

Why not use the standard and longtime and long established method of testing 
for controls by using the built in cancel feature? About the only downside 
is there are cases when the user might tab through the control and not enter 
anything. However, perhaps they WANT to do that, and perhaps they're going 
to tab BACK into the other control when they get the appropriate information 
for that control.

So, my approach gives the user freedom to move around anywhere in the form 
in any direction, and enter data in THEIR order. At the end of the day we 
STILL have to test the code at use/update time anyway.

I think it's a reasonable user interface to let users move around at will, 
and not nag them unless they actually change the control  value.

And I think it's a reasonable programming approach to put verification code 
where 99% of developers will expect the verification code to be placed....

Your mileage and thoughts may vary and your view may be different  on this 
issue...this is not the "only" way to approach this...

-- 
Albert D. Kallal    (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal@msn.com


0
Albert
1/7/2008 8:02:06 AM
Well, actually, this is the way I did it (as I explained in my answer to one 
of the other experts).  Problem is, and remains, I have no good documentation 
about the events.
Many thanks anyhow,

W

"Albert D. Kallal" wrote:

> "Linq Adams via AccessMonster.com" <u28780@uwe> wrote in message 
> news:7dd709939a2f2@uwe...
> 
> >
> > And how does this help if the user
> >
> > Doesn't enter the Combobox  at all
> >
> > or
> >
> > Enters the combobox but doesn't select a value, merely Yabs to the next
> > control?
> 
> Remember, the user asked WHAT event (before, or after update) of the combo 
> box to use. I think is VERY clear that the before update event is the clear 
> winner.  We were only given two choices by the user.
> 
> Of course I assume that most people here will also assume that in addition 
> to the above testing of the controls, there has to be some code that 
> eventually writes out, or uses this data (and tests that data before hand). 
> However we do want to give the user warning at the time when he uses the 
> combo box, but we WILL STILL need additional code if the control(s) NEVER 
> receive the focus.
> 
> Thus, I am of course assuming that the user Obviously realizes that 
> additional code at update time (or examine time) will be required. In fact I 
> don't know of any access developer that assumes that you can just use any 
> event on a control to verify the final data before writing out. We've never 
> EVER had that ability anyway. You either use data engine integrity or you 
> put in your own special code that test things and use your own custom 
> messages.
> 
> Furthermore we don't know if the users actually updating data, and with the 
> given information given we actually can NOT make that assumption.
> 
> The only thing we have at this point in time is which of the two events to 
> use, and clearly in my humble opinion of the before update event is the 
> correct event to use. We *could* use lost focus, but then again, why? We are 
> back to square one if the control NEVER receives the focus!!!
> 
> So, in addition to using the before update event,  if the control never 
> receives the focus, and the control is never modified, then I have to assume 
> that most people here have concluded that additional code WILL be needed 
> when the data needs to be used.
> 
> So perhaps I'm assuming too much here. Perhaps the obvious conclusion that 
> additional checking code will be needed at update, or at the time when the 
> data used perhaps was too much of an obvious conclusion on my part (but in 
> effect we've always had to do it that way).
> 
> So, yes....if I was coding this, I would use
> 
> 1) the before update event of the control
> and,
> 2) Additionally I would also have code at update (or examine time) that 
> tests the data. (so, fair question on your part).
> 
> Of course the person could use the lost focus event, but as we mentioned if 
> the control never gets the focus, then we still need the code at 
> update/examine time. Furthermore the lost focus event does not have a cancel 
> event, and I know that experienced developers will instinctively and 
> naturally look to the before update event for the controls validation code.
> 
> There might be a VERY small UI advantage to using the lost focus event, I 
> think this advantage does not out weigh the fact that every developer is by 
> natural instinct to look and find the verification code for that control in 
> the before udpate event. That's where verification code traditionally goes.
> 
> The above approach is pretty much par for the course, and a lot of my forms 
> do have the testing code in the before update event of a contorl, and ALSO 
> that of the form's before update event (or this case an unbound form, when 
> the data is to be used).
> 
> Why not use the standard and longtime and long established method of testing 
> for controls by using the built in cancel feature? About the only downside 
> is there are cases when the user might tab through the control and not enter 
> anything. However, perhaps they WANT to do that, and perhaps they're going 
> to tab BACK into the other control when they get the appropriate information 
> for that control.
> 
> So, my approach gives the user freedom to move around anywhere in the form 
> in any direction, and enter data in THEIR order. At the end of the day we 
> STILL have to test the code at use/update time anyway.
> 
> I think it's a reasonable user interface to let users move around at will, 
> and not nag them unless they actually change the control  value.
> 
> And I think it's a reasonable programming approach to put verification code 
> where 99% of developers will expect the verification code to be placed....
> 
> Your mileage and thoughts may vary and your view may be different  on this 
> issue...this is not the "only" way to approach this...
> 
> -- 
> Albert D. Kallal    (Access MVP)
> Edmonton, Alberta Canada
> pleaseNOOSpamKallal@msn.com
> 
> 
> 
0
Utf
1/7/2008 10:16:02 AM
Hi,
I don't know of any good documentation about the events.
One thing to take notice of is the events that have a cancel argument, these 
are very handy to know.
Another thing that I found hard to remember was the way that the before and 
after update events changed or disappeared when you moved from bound forms 
to unbound forms. There is a lot to learn about the events, your knowledge 
grows as you keep programming. One way to see in what order events fire is 
to step through code and see how and what makes it skip from event to event. 
Probably one of the best ways to get yourself some documentation that is of 
practical help in day to day programming is to do a search on these 
newsgroups on each event that is available in forms and reports.

Jeanette Cunningham

"W" <W@discussions.microsoft.com> wrote in message 
news:89A75983-7F9A-4E5C-AD82-C8B3A22E803D@microsoft.com...
> Well, actually, this is the way I did it (as I explained in my answer to 
> one
> of the other experts).  Problem is, and remains, I have no good 
> documentation
> about the events.
> Many thanks anyhow,
>
> W
>
> "Albert D. Kallal" wrote:
>
>> "Linq Adams via AccessMonster.com" <u28780@uwe> wrote in message
>> news:7dd709939a2f2@uwe...
>>
>> >
>> > And how does this help if the user
>> >
>> > Doesn't enter the Combobox  at all
>> >
>> > or
>> >
>> > Enters the combobox but doesn't select a value, merely Yabs to the next
>> > control?
>>
>> Remember, the user asked WHAT event (before, or after update) of the 
>> combo
>> box to use. I think is VERY clear that the before update event is the 
>> clear
>> winner.  We were only given two choices by the user.
>>
>> Of course I assume that most people here will also assume that in 
>> addition
>> to the above testing of the controls, there has to be some code that
>> eventually writes out, or uses this data (and tests that data before 
>> hand).
>> However we do want to give the user warning at the time when he uses the
>> combo box, but we WILL STILL need additional code if the control(s) NEVER
>> receive the focus.
>>
>> Thus, I am of course assuming that the user Obviously realizes that
>> additional code at update time (or examine time) will be required. In 
>> fact I
>> don't know of any access developer that assumes that you can just use any
>> event on a control to verify the final data before writing out. We've 
>> never
>> EVER had that ability anyway. You either use data engine integrity or you
>> put in your own special code that test things and use your own custom
>> messages.
>>
>> Furthermore we don't know if the users actually updating data, and with 
>> the
>> given information given we actually can NOT make that assumption.
>>
>> The only thing we have at this point in time is which of the two events 
>> to
>> use, and clearly in my humble opinion of the before update event is the
>> correct event to use. We *could* use lost focus, but then again, why? We 
>> are
>> back to square one if the control NEVER receives the focus!!!
>>
>> So, in addition to using the before update event,  if the control never
>> receives the focus, and the control is never modified, then I have to 
>> assume
>> that most people here have concluded that additional code WILL be needed
>> when the data needs to be used.
>>
>> So perhaps I'm assuming too much here. Perhaps the obvious conclusion 
>> that
>> additional checking code will be needed at update, or at the time when 
>> the
>> data used perhaps was too much of an obvious conclusion on my part (but 
>> in
>> effect we've always had to do it that way).
>>
>> So, yes....if I was coding this, I would use
>>
>> 1) the before update event of the control
>> and,
>> 2) Additionally I would also have code at update (or examine time) that
>> tests the data. (so, fair question on your part).
>>
>> Of course the person could use the lost focus event, but as we mentioned 
>> if
>> the control never gets the focus, then we still need the code at
>> update/examine time. Furthermore the lost focus event does not have a 
>> cancel
>> event, and I know that experienced developers will instinctively and
>> naturally look to the before update event for the controls validation 
>> code.
>>
>> There might be a VERY small UI advantage to using the lost focus event, I
>> think this advantage does not out weigh the fact that every developer is 
>> by
>> natural instinct to look and find the verification code for that control 
>> in
>> the before udpate event. That's where verification code traditionally 
>> goes.
>>
>> The above approach is pretty much par for the course, and a lot of my 
>> forms
>> do have the testing code in the before update event of a contorl, and 
>> ALSO
>> that of the form's before update event (or this case an unbound form, 
>> when
>> the data is to be used).
>>
>> Why not use the standard and longtime and long established method of 
>> testing
>> for controls by using the built in cancel feature? About the only 
>> downside
>> is there are cases when the user might tab through the control and not 
>> enter
>> anything. However, perhaps they WANT to do that, and perhaps they're 
>> going
>> to tab BACK into the other control when they get the appropriate 
>> information
>> for that control.
>>
>> So, my approach gives the user freedom to move around anywhere in the 
>> form
>> in any direction, and enter data in THEIR order. At the end of the day we
>> STILL have to test the code at use/update time anyway.
>>
>> I think it's a reasonable user interface to let users move around at 
>> will,
>> and not nag them unless they actually change the control  value.
>>
>> And I think it's a reasonable programming approach to put verification 
>> code
>> where 99% of developers will expect the verification code to be 
>> placed....
>>
>> Your mileage and thoughts may vary and your view may be different  on 
>> this
>> issue...this is not the "only" way to approach this...
>>
>> -- 
>> Albert D. Kallal    (Access MVP)
>> Edmonton, Alberta Canada
>> pleaseNOOSpamKallal@msn.com
>>
>>
>> 


0
Jeanette
1/7/2008 11:00:06 AM
On Sun, 6 Jan 2008 23:28:02 -0800, W <W@discussions.microsoft.com> wrote:

>Eventually, I programmed the OnEnter event of my Save button to verify if 
>all data have been put in the places and the format I want them to be.

<shrug> You already have code in the Click event, to actually save the data.
I'd just put the code there; if everything is OK go ahead and save the data,
if not issue a message and don't save. Putting this code in the Enter event
just splits it up and adds more complexity. Your choice though!

             John W. Vinson [MVP]
0
John
1/7/2008 5:13:09 PM
W,

I guess you know that when you select an event in the property box and press
F1, you get a help screen about that event. The examples in these help
screens have helped me the most.

FYI I put a function like the following in the form and call it in the
OnClick event of the Save/Close button

Private Sub SaveAndCloseButton_Click()
    DoCmd.RunCommand acCmdSaveRecord
    If DoConsistencyCheck Then
        DoCmd.Close
    End If
End Sub


'**** here is the function
Private Function DoConsistencyCheck() As Boolean
Dim bolSuccess As Boolean
    bolSuccess = True

    If IsNull(Me.School) And (IsDate(Me.StartDate) Then
        bolSuccess = False
        MsgBox "Please enter a school."
        Me.School.SetFocus
    ElseIf IsNull(Me.LName) Then
        bolSuccess = False
        MsgBox "Please enter a last name."
       Me.LName.SetFocus
    ElseIf IsNull(Me.FName) Then
        bolSuccess = False
        MsgBox "Please enter a first name."
        Me.FName.SetFocus
    ElseIf Not IsNumeric(Me.Status) Then
        bolSuccess = False
        MsgBox "Please enter a status."
        Me.Status.SetFocus
    ElseIf Not IsNumeric(Me.GenderID) And IsDate(Me.StartDate) Then
        bolSuccess = False
        MsgBox "Please enter a Gender."
        Me.GenderID.SetFocus
        Me.GenderID.Dropdown
    ElseIf Me.JobPlacement And IsNull(Me.Employment) Then
        bolSuccess = False
        MsgBox "You must select an Employment Status for students in Job
Placement."
        Me.Employment.SetFocus
        Me.Employment.Dropdown
    ElseIf IsDate(Me.StartDate) and Not IsNumeric(Me.TotalPrice) Then
            bolSuccess = False
            MsgBox "Please enter a total price."
        End If
    End If

    DoConsistencyCheck = bolSuccess
End Function


"W" <W@discussions.microsoft.com> wrote in message
news:89A75983-7F9A-4E5C-AD82-C8B3A22E803D@microsoft.com...
> Well, actually, this is the way I did it (as I explained in my answer to
one
> of the other experts).  Problem is, and remains, I have no good
documentation
> about the events.
> Many thanks anyhow,
>
> W
>
> "Albert D. Kallal" wrote:
>
> > "Linq Adams via AccessMonster.com" <u28780@uwe> wrote in message
> > news:7dd709939a2f2@uwe...
> >
> > >
> > > And how does this help if the user
> > >
> > > Doesn't enter the Combobox  at all
> > >
> > > or
> > >
> > > Enters the combobox but doesn't select a value, merely Yabs to the
next
> > > control?
> >
> > Remember, the user asked WHAT event (before, or after update) of the
combo
> > box to use. I think is VERY clear that the before update event is the
clear
> > winner.  We were only given two choices by the user.
> >
> > Of course I assume that most people here will also assume that in
addition
> > to the above testing of the controls, there has to be some code that
> > eventually writes out, or uses this data (and tests that data before
hand).
> > However we do want to give the user warning at the time when he uses the
> > combo box, but we WILL STILL need additional code if the control(s)
NEVER
> > receive the focus.
> >
> > Thus, I am of course assuming that the user Obviously realizes that
> > additional code at update time (or examine time) will be required. In
fact I
> > don't know of any access developer that assumes that you can just use
any
> > event on a control to verify the final data before writing out. We've
never
> > EVER had that ability anyway. You either use data engine integrity or
you
> > put in your own special code that test things and use your own custom
> > messages.
> >
> > Furthermore we don't know if the users actually updating data, and with
the
> > given information given we actually can NOT make that assumption.
> >
> > The only thing we have at this point in time is which of the two events
to
> > use, and clearly in my humble opinion of the before update event is the
> > correct event to use. We *could* use lost focus, but then again, why? We
are
> > back to square one if the control NEVER receives the focus!!!
> >
> > So, in addition to using the before update event,  if the control never
> > receives the focus, and the control is never modified, then I have to
assume
> > that most people here have concluded that additional code WILL be needed
> > when the data needs to be used.
> >
> > So perhaps I'm assuming too much here. Perhaps the obvious conclusion
that
> > additional checking code will be needed at update, or at the time when
the
> > data used perhaps was too much of an obvious conclusion on my part (but
in
> > effect we've always had to do it that way).
> >
> > So, yes....if I was coding this, I would use
> >
> > 1) the before update event of the control
> > and,
> > 2) Additionally I would also have code at update (or examine time) that
> > tests the data. (so, fair question on your part).
> >
> > Of course the person could use the lost focus event, but as we mentioned
if
> > the control never gets the focus, then we still need the code at
> > update/examine time. Furthermore the lost focus event does not have a
cancel
> > event, and I know that experienced developers will instinctively and
> > naturally look to the before update event for the controls validation
code.
> >
> > There might be a VERY small UI advantage to using the lost focus event,
I
> > think this advantage does not out weigh the fact that every developer is
by
> > natural instinct to look and find the verification code for that control
in
> > the before udpate event. That's where verification code traditionally
goes.
> >
> > The above approach is pretty much par for the course, and a lot of my
forms
> > do have the testing code in the before update event of a contorl, and
ALSO
> > that of the form's before update event (or this case an unbound form,
when
> > the data is to be used).
> >
> > Why not use the standard and longtime and long established method of
testing
> > for controls by using the built in cancel feature? About the only
downside
> > is there are cases when the user might tab through the control and not
enter
> > anything. However, perhaps they WANT to do that, and perhaps they're
going
> > to tab BACK into the other control when they get the appropriate
information
> > for that control.
> >
> > So, my approach gives the user freedom to move around anywhere in the
form
> > in any direction, and enter data in THEIR order. At the end of the day
we
> > STILL have to test the code at use/update time anyway.
> >
> > I think it's a reasonable user interface to let users move around at
will,
> > and not nag them unless they actually change the control  value.
> >
> > And I think it's a reasonable programming approach to put verification
code
> > where 99% of developers will expect the verification code to be
placed....
> >
> > Your mileage and thoughts may vary and your view may be different  on
this
> > issue...this is not the "only" way to approach this...
> >
> > -- 
> > Albert D. Kallal    (Access MVP)
> > Edmonton, Alberta Canada
> > pleaseNOOSpamKallal@msn.com
> >
> >
> >


0
Powderfinger
1/9/2008 10:22:25 PM
Reply:

Similar Artilces:

Unpredicatable BeforeUpdate event
Hi, I am totally new to programming. I have tried to design a form with some code in the beforeupdate. The behaviour of the form has baffled me so much i can’t understand where it’s going wrong. It’s totally unpredictable. So, friends please don’t get impatient as i am reproducing the entire code here but please help me solve this problem. I have a form with a few unbound controls . The fields are: FromDate ToDate Applicable period(this is an option Group) OldRate (if applicable in earlier time) NewRate ( if applicable at present). And cmdADD button and cmdCANCEL bu...

Form beforeinsert and beforeupdate events
When adding a new record do both get fired? I need to set a date when a status field gets changed, so I need to set it in initial insert and also when updating an exisitng record; currently I have in form before update event: If Me!StatusID <> Me!StatusID.OldValue Then Me!StatusDate = Now() End If Is this sufficient? Thanks. Yes, both events fire for new records, in this order: BeforeInsert ==> BeforeUpdate ==> AfterUpdate ==> AfterInsert -- Doug Steele, Microsoft Access MVP http://I.Am/DougSteele (no e-mails, please!) "mscertified" <rupert@tige...

Very frustrated with BeforeUpdate event
Hi I'm mainly a lurker and I've been searching through the list for a few days trying to find an answer to my very frustrating automatic save problem. I have a form with a subform in it. In the subform there are 4 required text fields and 4 number fields. I have a Save button that I want to use EXCLUSIVELY to save the record. Next to it is a Close button that I'd like to use EXCLUSIVELY to close the form. I do not want the record to be saved when the close button is hit. I just want the form to close. I know I have to write some code in the BeforeUpdate event of the subform. I...

Listbox will not Requery AfterUpdate
I am running Access 2007. I have two listboxes sitting side by side on the same form. One has phone number categories - lstCategories The second listbox has name, phone numbers - lstPhoneNumbers Both listboxes are unbound I had this working once where you could click the category in the first box and it would filter the second listbox to the phone number in a different category. Example: click category box select family, friend etc. the second box would only show numbers of family or category you selected in the first box. Now, the boxes work perfectly fine as far ...

why my BeforeUpdate does not work?
I intentionally tried both conditions but MsgBox does not start. Where did I do wrong? Private Sub cboFrom_BeforeUpdate(Cancel As Integer) If Me.From < DMin("TimeIn", "qryVisitData") Then MsgBox ("FROM cannot be earlier than downloaded data range") Cancel = True End If If Me.From > Me.To Then MsgBox ("FROM must be same or earler than TO") Cancel = True End If End Sub Hi Song Su, Is your combobox named "Me.From" or "Me.cboFrom". Judging from the event name, it's unlikely ...

rollback combobox to 'BeforeUpdate' value
How do I set a combobox to a previous value? When finished updating a particular record the user selects an identifer in a combobox to advance to the next desired record. I use the BeforeUpdate event of the combobox to ask a yes/no question. If NO I want to stay with the current record and this works. the problem is that the combobox has been advanced to the new selection and stays there. Now I have the identifer for one record in the combo box but the form is still (as it should be) on the current record. I need to roll back the combobox to what it was before the update bu...

BeforeUpdate problem
I have a form bound to a client list that shows client status and the assigned salesperson ([assignment] field). I have placed code in the BeforeUpdate event of the [status] field that, when the client status is changed from "active" to "inactive" prompts the user for confirmation, and with an affirmative response calls a module procedure that updates records in two other tables, as well as removing the salesperson [assignment] in the underlying table for the bound form. The (2115) error occurs, I assume, when the form's BeforeUpdate event attempts to fire. S...

Check for Duplicate value BeforeUpdate
Hello all, I have a problem with updating on my form. I have a form, TrainingHistory, that is linked to a table by the same name. There are three fields showing: FullName, ClassName, and DateTaken. For each person, I am only interested in the MOST RECENT date they took any given class. So what I want is to be able to enter a name and class, and have Access check the table for this combination of name and class. If such an entry already does exist, I would like the form to bring up that entry, and that entry alone, for editing of the date. There should also be a message explaining what ju...

BeforeUpdate or AfterUpdate ?
Hi all, I have an unbound form in which I have (amongst others) two comboboxes with mandatory data. Although I present a combobox, limited to the choices to pick out, people manage not to fill in those data and to jump via the TAB-key to the next field. Of course I’ll have NULL value for this combobox, but how can I force the user to look for the correct row ? In the BeforeUpdate or in the AfterUpdate event ? I have some code like : Private Sub CboAfterUpdate() if isnull(me.Cbo) then Beep Msgbox(“You must choose a value”) Me.cboAfter.setfocus endif end sub But this does not se...

AfterUpdate/BeforeUpdate and SetFocus
I have some problems with the SetFocus command in a Userform with an AfterUpdate or BeforeUpdate routine. To make it clear to you, I made a very small Userform to demonstrate it. It only contains 8 TextBoxes and this code: Code: Private Sub TextBox01_AfterUpdate() Me.TextBox08.SetFocus End Sub - Private Sub TextBox02_BeforeUpdate(ByVal Cancel As MSForms.ReturnBoolean) TextBox08.SetFocus End Sub - Private Sub TextBox03_Exit(ByVal Cancel As MSForms.ReturnBoolean) TextBox08.SetFocus End Sub - Private Sub TextBox04_Change() TextBox08.SetFocus End Sub I expected that in ...

complicated subform beforeupdate
access 2003 mainform is f001Projectreview with subform f015KeyMilestones(PK ProjectID) I am trying to accomplish the below notes with the below code. It works well unless... user selects KeyMilestonesSubID = 12 and does not enter UnitNo. It prompts for UnitNo and auto changes UnitNo to 0 and also prompts for AuctualDt This is what I wanted. Now if user changes their mind and selects KeyMilestonesSubID = 8 It still give user the msg - All Units can only be used with PM080 and PM670(which is KeyMilestonesSubID 12 or 20). Must enter Actual Date or check N/a if Quality Gate is no...

access 2007 / beforeUpdate in a form
Dear all, From access 2003 on-line doc abour the BeforeUpdate of a control in a form: "If the user enters a new value in the control, the OldValue property setting isn't changed until the data is saved (the record is updated). If you cancel an update, the value of the OldValue property replaces the existing value in the control." However, in access 2007, If I cancel an update, the value of the OldValue property doesn't replace the existing value in the control.=> Is it possible to get the same behaviour (re-changing the value triggers another beforeUpdate event)? Regard...

BeforeUpdate without update?
I have a form which is using Oracle as the datasource = single table and the controls are mostly bound (2 textboxes are not bound and exist in order to display names from ids). the form displays only a single record at a time. If I make changes to a new record (i.e. fill in the first field) and attempt to navigate to the next record, the beforeUpdate event fires and then I get an error saying such and such a field is null and must be populated first,etc. This works everytime. My form also has 2 buttons to navigate away from the form (all other navigation such as closing the form, etc. have b...

Access2000: BeforeUpdate for TextBox
Hi On a form I have 2 controls, txtHours & txtMinutes. Whenever there is entered 60 or more minutes into txtMinutes, I want full hours added to txtHours (or txtHours value replaced, I haven't decided yet), and set reminder as new value for txtMinutes. Something like: Private Sub txtMinutes_BeforeUpdate(Cancel As Integer) If Me.txtMinutes < 60 Then Else Me.txtHoues = Me.txtHoues + Int(Me.txtMinutes / 60) Me.txtMinutes = Me.txtMinutes Mod 60 End If End Sub Current code returns an error "The macro or function set to the BeforeUp...

Form BeforeUpdate Ignoring Cancel
I have a situation where I must verify that both of two related controls have been entered or neither has been entered. The following code does just what I want except that Access seems to be ignoring the Cancel value: Function CrossCheckKeys(Cancel As Integer) Dim CurrForm As Form: Set CurrForm = Screen.ActiveForm With CurrForm If (IsNull(.Controls("comSinkKey")) And Not IsNull(.Controls("comSrceKey"))) _ Or (IsNull(.Controls("comSrceKey")) And Not IsNull(.Controls("comSinkKey"))) Then If IsNull(.Controls("comS...

AfterUpdate Now() to table
I am using: CurrentDb.Execute "UPDATE tbl_Projects SET DateUpdated = Now()" as suggested here, but it is updating ALL records, how do I specify the record that was actully changed? If you are talking about TimeStamping a record that was updated on a form then you want your code in the BeforeUpdate event of the form. In this case you do not need SQL but simply: [DateUpdated] = Now MeSteve wrote: >I am using: >CurrentDb.Execute "UPDATE tbl_Projects SET DateUpdated = Now()" >as suggested here, but it is updating ALL records, how do I specify the >record that w...

A2K format
G'day ppl Have a form which after the user has completed all data input can invoice job out. I have a command button: Private Sub InvoiceBtn_Click() Dim InvoiceResp As Integer InvoiceResp = MsgBox("Are you sure you want to mark this record for Invoicing ?????", vbYesNo) If InvoiceResp = vbYes Then Me.Invoice = 1 Me.WeekNo = Me.DateDel Else DoCmd.CancelEvent End If End Sub What I would like to have happen is that before it updates Me.Invoice, it checks that the [PackStatus]=6 (6=Pack is Delivered). So if the criteria doesn't match then di...

AfterUpdate Problem
I need to flash an "RE-ORDER ALERT" message after inventory level falls below re-order level. The message only flashes up when I move to a next record and back after a DoCmd.Save. I need the message to flash immediate after a Save. Note. The message is a flashing label on the form. Thank you. Perhaps you could code it to actually flash before DoCmd.Save is processed. Once you're into that code string, it will be run. Or, maybe consider a Message Box. I like this idea because it forces the user to interact with the reorder message. No one can say "I didn'...

Cancel/BeforeUpdate Event Procedure
I have a main form Containers with a subform ContainerSubstances. The latter has a combo box showing the substances in the Substances table. If the desired substance is not in the combo, the user may bring up the Substances form in Add and Dialog mode. The user can press Save or Cancel from the latter form, and both work as designed. If Save is pressed, the combo box on the original subform is requeried to include the new value, and then the new value is selected by the code, and the Substances form closes, and the user returns to the Containers form, with focus set in the ...

Unbound combobox AfterUpdate
Hi On some form I have several unbound combobox controls. Whenever some of them is changed, I want: 1. reset the values for other combos on same form; 2. reset Filter and FilterOn properties for subform on same form; 3. reset Rowsource for a record locating combobox on this subform. Currently I use combo's AfterUpdate's events for this - like here: Private Sub Combo1_AfterUpdate() Me.Combo2 = 0 Me.Combo3 = 0 If Nz(Me.Combo1, 0) = 0 Then Me.MySubform.Form.Filter = "" Me.MySubform.Form.FilterOn = False ...

blinking form afterupdate
Hi, When i use this command: DoCmd.DoMenuItem acFormBar, acRecordsMenu, 5, , acMenuVer70 The form blinks with every update. Is there a way to prevent the form from blinking ? I hope to hear from you ! Best regards and thanks in advance, Pierre This code requeries the form and displays any changes to the data. Where are you using that code - is it on a button or some other event? Jeanette Cunningham MS Access MVP -- Melbourne Victoria Australia "Pierkes" <info@advisearch.nl> wrote in message news:4bf61674$0$31931$703f8584@news.kpn.nl... > Hi...

AfterUpdate Requery
I'm having a problem with Requery. I have 7 combo boxes that are cascading. One gets it's data from the previous one. The first three requery and blank out the combo boxes if the item that was selected isn't in the new list. Although the last four do requery and get a new list, they keep the previous selected text even if it isn't in the new list. I set the Limit To List option but that didn't have an effect on the last four combo boxes. I posted the different ways I've tried requerying below. The only one that seems to remove the data is DoCmd.Requery but on...

Re: A2K format
"NoodNutt" <mclind1@bigpond.com> wrote in message news:... > G'day ppl > > Have a form which after the user has completed all data input can invoice > job out. > > I have a command button: > > Private Sub InvoiceBtn_Click() > Dim InvoiceResp As Integer > InvoiceResp = MsgBox("Are you sure you want to mark this record for > Invoicing ?????", vbYesNo) > If InvoiceResp = vbYes Then > Me.Invoice = 1 > Me.WeekNo = Me.DateDel > Else > DoCmd.CancelEvent > End If > End Sub > > What I wo...

Delete code competing with BeforeUpdate validation
I put code in the Before Update event of my form to verify that two fields are complete (i.e., Not Null) before saving. The code is: Private Sub Form_BeforeUpdate(Cancel As Integer) If IsNull(Me.FirstName) Then MsgBox "Please enter a first name." Cancel = True Me.FirstName.SetFocus ElseIf IsNull(Me.LastName) Then MsgBox "Please enter a last name." Cancel = True Me.LastName.SetFocus End If End Sub Also on my form is a Delete button that deletes the record. The problem is that if the user starts a new record, and then clicks...

AfterUpdate Event for TextBox
I have this code for the afterupdate event on a text box that has data in it. Me.Text732 = Replace(Abs(Val([Text732])), ".", "") When I past this data 0000272400123456 into the text box, it gets rid of the 0000, becomes 272400123456 But if I past this kind of number 4223697600059898, it turns it into this 42236976000599E+15 If I take the coding away and past the 4223697600059898 number, it stays the same and doesn't get changed to the +15. Any suggestions or changes to code to fix this? Thanks! Curtis if its a text field then it shouldnt be modifying any v...