Event order when clicking away from a field

[Billd]

I have a subForm controlling transaction lines inside another form. The
subForm has a RetailPrice field. The user enters a value and then he/she
immediately clicks (before ENTER or TAB ) onto a button in the mainForm that
will print off the invoice.
There are events associated with that field that must fire before moving
away from the focus of that field. None of these fire before the click event
of the button has run - Why is this and how can I program around the problem?

Access 2003 sp3+

TIA

Bill

 

[Allen Browne]

Each form has its own active control, so the focus does not have to leave
the active control in the subform in order to make another control active on
the main form (the command button.)

But moving focus to the main form will save any edits in progress in the
subform. If you are seeking to do validation in a control in the subform,
move that code into the subform's BeforeUpdate event instead. Then any
attempt to move away from the subform control on the main form (to a button)
will have the effect of saving the subform's record, which triggers
Form_BeforeUpdate, and so your code runs in time.

 

[Billd]

Really appreciate answer. My one issue is with the Form.Dirty command giving
errors if this event is called. Should I just accept this and code it away.
Without Form.Dirty being in almost every event, ad hoc record errors occur
everywhere, and thats with being VERY diligent about record locking.

Appreciate your opinions.

Bill

 

[Allen Browne]

What are you doing in the form's Dirty event?

If you are (say) setting some kind of flag, you can reset it in
Form_AfterUpdate.

You don't need to roll your own locking. Access already gives you several
locking strategies, which work well. Optimistic locking is best, unless you
have a reason to use something different.

Perhaps if you tell us you need to achieve, we can suggest which form events
can give it to you.

 

[Billd]

Hi,

No,not in th Dirty Event, but using the:-

IF Form.dirty then
Form.Dirty = false
endif

as code in the BeforeUpdate Event.

if blows over on the Form.Dirty = False

Its not normally necessary but some of the networks and systems my clients
can have some dodgy network cards and cables. Recently nVidea ones gave me
grief. Especially in manufacturing environments. It only takes one going
down. Optimistic locking would be great if everybody had a good server,
preferably not NT. Only about 3/5th are using opportunistic locking
sucessfully.

As I said I would be happy to code around this method if you feel its the
only way.

Cheers

Bill

 

[Allen Browne]

It is often a good idea to explicitly save, but you don't need to in
Form_BeforeUpdate.

Access doesn't fire that event unless the form is dirty. And the event has
to complete *before* the record can be saved, so you can't force the save
while the event is still running.

 

[Billd]

Thanks for keeping with this one. The theory is that after entering the new
retail price it recalculates the values of the lines and the whole order
based on that line.

If it is not saved then the SQL statements that balance it up will not work,
locking errors etc, hence the need for the Form.Dirty prior to the
calculations. I have to accept that this won't happen due to Access not
running the events/triggers in the right order ( My Words ).

To allow for this I shall have to run a whole order calculation in the
begining of the click event of the buttons in the parent form (and any other
field that is affected by this) in the parent form, including the exit form
option. It is nasty. Maybe if I blocked all exits until after the Exit /
After Update Event of the field, forcing the operator to press "Return",
"Tab" or click else where on the sub form, then the problem is solved. Time
for a basic review.

Really appreciate your help for us 'Coal-face' Access workers, your help web
pages have been very helpful, especially when the 2007 Access was first
released.

Cheers

Bill

 

[Allen Browne]

I'm really not clear what you are trying to achieve.

Perhaps you need to use the AfterUpdate event of the controls to force the
save, so you want:
Me.Dirty = False
in each control's AfterUpdate? That would do the job, but could multiply the
number of unnecessary writes (and so the chance of clashes.) There might be
a better way to achieve the calcuations.

 

[Billd]

I agree very messy. I have found a rather neat way of making the control
being held until the exit event is completed, forcing the operator to "ENTER"
or "TAB" away. This would mean that all events, record writes and hence all
calculations are completed in the same way.

Form.Modal = True in the field Change event
Form.Modal = false in the field Exit event

Making the operator concentrate on the data entry and ensureing correct
validation. Cobol where are you?

Many thanks again. I think I will go this route and make it a training issue.

Cheers

Bill