Force a form to be Dirty

[clarksquonk]

Hi,

I need to know how to force a form (and therefore its underlying recordset) to be dirty. I tried setting the Form.Dirty property to True but that didn't do anything.

I have a form with many bound controls on it. I have an bound combo box (bound to a separate table from the form's recordset) with a list of abbreviations that the user can choose from. When they choose one, that abbreviation is copied to a bound Description text box. The problem is, the Description field does not realize it has been changed, at least as far as I can tell. I tried working with the control's Change and Dirty even but neither fires off when the abbreviation is copied to the Description text box. Those events only seem to be working when 1) text is pasted into the control and 2) when the user types in the field.

So, any help?

Clark

 

[thornmastr]

Are you using the forms dirty event. It sounds as if you are and therefore constrained by the following rules:
Modifying a record within a form by using a macro or Visual Basic doesn't trigger this event. You must type the data directly into the record or set the control's Text property.
• This event applies only to bound forms, not an unbound form or report.

I don’t use this method. You can, in the forms before update event test for the dirty status, and if anything within the underlying recordset has been updated (and, if the underlying query is updateable), the record will be dirty.

You cannot set the dirty property to true other than to modify an existing value and the recordset must be updateable.
Robert Berman
Data Base consultant
Vulcan Software Services
thornmastr@yahoo.com

 

[MichaelRed]

You COULD set the tag property of the control to some value whenever you post information via code. In the FORM BeforeUpdate event, loop through the controls collection checking for the tag value. If it is present, then treat the form as "Dirty".

MichaelRed
m.red@att.net

There is never time to do it right but there is always time to do it over

 

[thornmastr]

Michael,

Assuming he is using a bound form with an underlying updateable record source, what does this solution provide that a simple test for the dirty property not offer. If he decides to treat the record as dirty based on the value in the tag property, if the record has not been modified, issuing a write of a non modified record causes Access to do what? I think it does nothing. If you set a break point in your before update event, you will find that moving from one record to another will not fire the before update event unless a form value has been dirtied.

If the form is not bound, he should be using a class structure to control his I/O, however I think he is using a bound form. It might be he is using a query behind the form that is not updateable and is trying to force the issue.

Just my $0.02 worth.
Robert Berman
Data Base consultant
Vulcan Software Services
thornmastr@yahoo.com

 

[MichaelRed]

Oops. Snookered AGAIN! Lost the memory of the BeforeUpdate not firing unless dirty is true. Guess it is back to the drawing board, as I cannot find an event which fires when simply moving to a different record (beforecurrent?).

Perhaps the code to check for the changes to the tag property could be in the OnCurrent event?

Some messy issues re which record the changes are applied to, as it is NOT the current (usually) one. But the tag property would survive the change of the record.

Not an 'elegant' soloution.

Since the use of the form implies at least user attendance, perhaps the addition of a simple yes/no field (check box) which the user MUST set before moving to the next item could be used to force the dirty event, then the original works (use tags to hold values)?

Still not elegant.

Use SendKeys to paste the combobox selected text to the textbox. Messy -at best- but it does meet the criterial for setting 'Dirty'. With only a bit of angst, I have this on "working".

Private Sub txtDummy_AfterUpdate()
    If (Me.Dirty) Then
        Me.chkDirty = True
     Else
        Me.chkDirty = False
    End If
'    Stop
End Sub

Private Sub txtEndDt_AfterUpdate()
    Dim MyText As String
    Dim MyCtrl As String
    MyCtrl = Screen.ActiveControl.Name
    Call basDoDate(Me, Me.txtEndDt)
    MyText = Me.txtEndDt
    Me.txtDummy.SetFocus
    SendKeys MyText
    DoEvents
'    Me(MyCtrl).SetFocus
End Sub

In the first routine, the point is to simply set an indicator that the form dirty property has actually been set. The commented out instruction (stop) was only to aid in getting the syntax checked.

The second procedure is to actually use sendkeys to place (paste) a value into the control. Note, this CONTROL need not be bound, just that the form be bound. I get an error attempting to set the focus back to the control which is actually setting the dummy control. Commenting this out permits the procedures to work and sucessfully set the check box -after I manually move the focus off of the dummy rtext box.

A bit of 'play time' programming should permnit the whole of hte operation to proceede smoothly.

MichaelRed
m.red@att.net

There is never time to do it right but there is always time to do it over

 

[JeremyNYC]

Hmm. This worked for me:
Private Sub Command60_Click()
Me!txtBankID.SetFocus
Me.Dirty = True
End Sub

I had to set the focus to a control I could update, but this seemed to do the trick.

Jeremy =============
Jeremy Wallace

http://www.AlphaBetCityDataworks.com

Designing, Developing, and Deploying Access databases since 1995.

 

[MichaelRed]

Interesting /weird. Every method I used to set the dirty property of a form just got me off into err land.

Help says:

This property set or read using a macro or Visual Basic.

but the "Set" obviously has some 'quirks'?

MichaelRed
m.red@att.net

There is never time to do it right but there is always time to do it over

 

[JeremyNYC]

Well, the only "quirk" I found was clearly pointed out in the error I got, which said something to the effect of "To do this action the focus must be in a control that can be edited." So I just set the focus to a control I could edit, and it worked.

Jeremy =============
Jeremy Wallace

http://www.AlphaBetCityDataworks.com

Designing, Developing, and Deploying Access databases since 1995.

 

[thornmastr]

Just simulated Jeremy's stuff, and it did work.......BUT.......
1. the before update event for the form never fired.
2. Repeating the experiment then changing the focus to a text box, and using the debugger keying in....
?me.dirty

which should have kicked back true for the form since I just set it with Jeremy's routine.....<sigh> returned false....so I think it matters not. If Getz says you can't set it....you can't set it. Robert Berman
Data Base consultant
Vulcan Software Services
thornmastr@yahoo.com

 

[JeremyNYC]

Well, I didn't read the thread, and just now only scanned it, but I didn't see any mention of Getz saying this.

And ?me.dirty gave me an error, saying the variable didn't make sense in this context, but ?forms!frmAccount.dirty gave me True.

And the before update doesn't fire when a record becomes dirty, only when it's saved. If I just click on this button and save it, my before update event fires as it should.

Now I certainly don't pretend to have combat tested this code, and there may be easy ways to make it fall over, but it still seems to work for me.

Jeremy =============
Jeremy Wallace

http://www.AlphaBetCityDataworks.com

Designing, Developing, and Deploying Access databases since 1995.

 

[thornmastr]

Hi Jeremy,

If you will notice, all three of us, you, Mike, and I, are all getting different results. I mentioning Getz because he advocates using the forms dirty property for a record update, ie,

If me.dirty then
me.dirty = false
endif

which definitely forces an update and does fire the forms before update event. Getz also explains the way the property is used by Access and that you cannot set it directly, only through modifying an element on a bound form.

I use the test often and it works consistently and very well. I have never, until I tested your routine, ever attempted to set the forms dirty property. Of course, as I stated before, I think it is a fallacious result.

Again, IMNSHO, if 3 people get different results, use it the way you know it works for you and keep a skeptical view of the other approaches.


Robert Berman
Data Base consultant
Vulcan Software Services
thornmastr@yahoo.com

 

[JeremyNYC]

Robert,

Certainly your last paragraph is spot on, and I don't mean to be argumentative, but...

You say that the three of us got different results, but it seems to me that that's because we were doing different things, not because Access behaved differently for the three of us.

In any case, I'm sure this is not such a huge point that we should spend our entire afternoons on it. If, however, you'd like to keep looking at it, let me know and I'll send you a tiny mdb with my form and code in it.

Jeremy =============
Jeremy Wallace

http://www.AlphaBetCityDataworks.com

Designing, Developing, and Deploying Access databases since 1995.