How to trigger event on selected field changes

mlai08

Registered User.
Local time
Today, 13:27
Joined
Dec 20, 2007
Messages
110
I want to make sure that users of a form need to perform an action first before changing on some selected fields on the form. My thought is to fire up a message when either of those fields has changed. I can not use the OnDirty event on those fields since I only want the message to appear once when either of those fields have changed. Ideally, the event should setfocus back on the field which has been changed and the user can undo the change.

I tried to write the following codes under the Form Current event but it gives me a type mismatch error.

Dim blnChkChange As Boolean
blnChkChange = False
If Me.fieldA.OnDirty = True Or Me.fieldB.OnDirty = True Or Me.fieldC.OnDirty = True Then

If blnChkChange = False Then
Msgbox "alert"
blnChkChange = True
End If

End If

Wonder if anyone can enlighten me on this. :) Thanks
 
1. You can't use Current with Dirty.

2. What action do you need them to take before they can enter data in the other controls?

3. You can set the controls' Enabled property to NO and then enable them once your action has taken place.

4. You normally use the form's BEFORE UPDATE event to validate your controls and then cancel the update using

Cancel = True

if the validation fails.
 
Hi Boblarson,

I appreciate your comments but I did try to use the codes in BeforeUpdate but got the same error of type mismatch. I need users to click a button on the form to archive data of those fields first before new changes are made. I could disable those fields first as you suggested but new user may not know the prerequisite of the archive action. My objective is to alert them on what to do only ONCE whenever they change any of those fields. I don't want the message to pop up again after user has performed data archive and start making changes on those fields.

Thanks
 
Hi Boblarson,

I appreciate your comments but I did try to use the codes in BeforeUpdate but got the same error of type mismatch.
The code you listed is not right at all. You don't test for Dirty in the Before Update event. If a form isn't dirty, then it won't fire the Before Update event to begin with.

I need users to click a button on the form to archive data of those fields first before new changes are made. I could disable those fields first as you suggested but new user may not know the prerequisite of the archive action. My objective is to alert them on what to do only ONCE whenever they change any of those fields. I don't want the message to pop up again after user has performed data archive and start making changes on those fields.

Thanks

Why have them click the button to archive before making changes. It should be transparent to the user. You can use the .OldValue property of a control to get that information and store it when the Before Update Event is run.

I guess I don't understand the process either. Can you explain a bit further as to why you need them to click the button to archive things before going on and how you plan on making sure that the archive happens only once for that particular set of data?

What are you using to archive the data? Are you using a Query to append to another table?
 
Hi Bob,

I meant to use the OnDirty property of the fields not the form on the Form Before Update event. So, my logic is that only changes made on selected fields will trigger off an action with no impact on other fields of the form.

I want users to archive a contractor's employment information such as contract start date, end date, hourly rate etc. The button will run an action query to append this data to another table and clear the contents on those contractor info fields on the form, allowing users to enter new data. This happens when the contractor starts a new or renew existing contract. The whole idea is to make sure users archive current contract info befor entering new data so that we can keep track of the contractor's hiring history.
 
Fields do not have a .Dirty property, only a form has .Dirty. There is a big speed-bump in the design.

As Bob Larson says, you should make this sort of thing transparent. However, based on your description, I cannot "see in my head" a way to retrofit this requirement.

It SOUNDS like your problem is that you allow users to edit existing records. Which makes me VERY suspicious that you are doing so because your database is not normalized. Otherwise, you could just create a new record for the same contractor and just use drop-downs to select what needs to be selected.

It is my best advice to step away from the forms and look hard at the normalization of your database before proceeding any more along these lines. Not trying to be harsh here because we have all learned these lessons, but I sense an impending train wreck unless you absolutely assure proper normalization of these records you are updating.
 
Fields do not have a .Dirty property, only a form has .Dirty. There is a big speed-bump in the design.

As Bob Larson says, you should make this sort of thing transparent. However, based on your description, I cannot "see in my head" a way to retrofit this requirement.

It SOUNDS like your problem is that you allow users to edit existing records. Which makes me VERY suspicious that you are doing so because your database is not normalized. Otherwise, you could just create a new record for the same contractor and just use drop-downs to select what needs to be selected.

It is my best advice to step away from the forms and look hard at the normalization of your database before proceeding any more along these lines. Not trying to be harsh here because we have all learned these lessons, but I sense an impending train wreck unless you absolutely assure proper normalization of these records you are updating.

Thanks for your advice. The database is normalized. We have an employee table capturing employee info including contract data. We want to see all current data on the employee input form but allow the option of archiving contract info to an archive table and let user to enter new contract data on the input form when the contractor renew the contract. We of course has to allow users to edit current contract data in case of error.

I don't really see a big issue with this set up. I could embed a contract info subform bounded to the archive table in the employee input form, so users can just add new contract record when current contract is renewed but it defeats users' requirement of only seeing contract info of existing contract. They prefer to keep contract histroy in a separate table.:o
 
Keeping history in a separate table is not necessary. Just add a Yes/No ProjectClosed [whatever you want to call it] field and let the user select Yes or No when the project is closed then you can filter the record source to not display closed projects. Add another filter option to display closed projects if the user so desires to see them.
 

Users who are viewing this thread

Back
Top Bottom