Needing an isFormDirty test/method/function for a form with Unbound Fields

[bxdobs]

Warning! dbase/Foxpro Dinosaur Alert! (translation ... Old Person please be kind)



Thanks in advance for any insight you can share so I can hopefully keep whatever grey matter I have left intact

Using 32 Bit mdb files to maintain backward compatibility with OFS Pro 2003 in 2003, 2016 and 2019

Grew up with the cardinal RULE: thou shalt NEVER use forms with BOUND fields

Seems to be a huge amount of noise on the topic of Unbound Fields with respect to determining a Dirty state ... in my poking around, I seem to have come away with the notion that: UNBOUND fields do NOT use Access's built-in Dirty Flag Logic (logic which appears to either use the Before & After properties OR the form.controls.item[n].oldvalue & value fields)

Is this notion valid? OR Have I missed something?

Does this mean one has to resort to manually creating code similar to the form load logic that populates the UNBOUND fields?

Basically, generate logic that compares each source value against its associated/current form field value?

OR

Adding After Events for each field? (there appears to be some suggestions that these events don't work properly with Unbound Fields)

Surely somebody has found an easier way of setting/triggering a form global gloIsMyFormDirtyFlag for Unbound Fields?

My attempt to create (simulate) a generic fnIsFormDirty function failed because it seems: oldvalue ALWAYS = value

Private Function fnIsFormDirty() As Boolean ' expected to return true if form fields have changed
 Dim inI As Integer
 On Error Resume Next 'null content triggers errors just ignore and carry on (null typically means the source wasn't populated) 
 fnIsFormDirty = False
 For inI = 0 To Me.Form.Controls.Count - 1 ' zero is a number
   ' didn't review all the access control types but the ones in use on this form >= 109 worked with this logic
   ' some fields are locked because they contain read only values
   If Me.Form.Controls.Item(inI).ControlType >= 109 And (Not Me.Form.Controls.Item(inI).Locked) Then
    fnIsFrmDirty = fnIsFrmDirty Or (Me.Form.Controls.Item(inI).Value <> Me.Form.Controls.Item(inI).OldValue)
    Debug.Print Me.Form.Controls.Item(inI).name; " "; Me.Form.Controls.Item(inI).Value; " "; Me.Form.Controls.Item(inI).OldValue
   End If
 Next
End Function

Given a busy form with many Unbound fields that are being populated from an openrecordset, currently looking for a simple or easier way to satisfy the following form functions:

Form Load()
populates the fields from openrecordset

Form cancel/close()
needs to determine if there has been a change and warn the user before tossing changes

Form save/close()
needs to determine if there has been a change and give the user a chance to recheck their changes

Form Delete()
needs to determine if there has been a change and give the user a chance to abort

Form Print()
needs to determine if there has been a change to provide the user the chance to save/update before printing

fncSave()
updates the openrecordset from the form fields

fnIsFormDirty()
returns true if form data has changed

[pbaldy]

You're making life a lot harder than it needs to be. You'll find most Access developers use bound forms most of the time. I suspect the rule of thumb is "use bound forms unless there's a compelling reason not to". I've used unbound forms now and then, for example when I created apps that had to run over a VPN and I wanted to minimize what went back and forth over the wire. I'd say at least 95% of the forms I've created over the years were bound.

To your question, in one app I ran audit trail code on an unbound form. I determined changed fields by comparing a recordset of the existing data to the form controls I think.

[Micron]

Grew up with the cardinal RULE: thou shalt NEVER use forms with BOUND fields

Never heard/saw that; seems counter intuitive to me. If there is a way to trap form level edits for an unbound form, I'm not aware of it. Nor can you use OldValue property for an unbound form control. Nor can an unbound form dirty property be True (AFAIK). The difficulty in dealing with unbound forms is enough for me to avoid them as much as possible. At best, I think you could create a function in a form module that sets a form module boolean variable to True. In whatever form event is appropriate for your case (close event?) you could check the value of the variable and take appropriate action. To facilitate 'connecting' the function to any number of controls, you could select many in design view as necessary, choose a property (afterUpdate?) and enter the function name as the code to run upon that event happening. NOTE: it must be a function; cannot be a sub. AfterUpdate will run for unbound controls (assuming the control even has that event).

Or you could ditch the notion about unbound forms.

[bxdobs]

Or you could ditch the notion about unbound forms.

Thanks for that push ... need to review this particular form to ensure nothing depends on its fields remaining unbound ... this particular app was written in OFS Pro 2k many years ago ... had a request to make a minor change (added a revision field) and the entire application stopped working ... may have to do a dump and reload of the form source.

[CJ_London]

I agree with the other comments - using unbound forms is a lot of hassle but accept are required on rare occasions.

If you want a bound form but do not want to automatically update when the user moves to another record/closes the form etc, put code in the form before update event to verify if the record is to be updated.

If you want to be able to change a bunch of records and update in one go (such as entering a new invoice with multiple invoice lines), consider using a bound form with either begintrans/committrans functionality or an ADO disconnected recordset. Note that with ADO, you will lose some of the built in right click menu options around filtering and sorting as the method is different from forms provided DAO functionality