Hey guys,

 

I'm trying to make a script trigger only commit a record when the contents of it have been changed and the field has been exited.

 

OnModify forces the change after every keystroke, where as OnExit will commit the record whether you've changed anything or not. I've tried adding validation onto the OnExit so that it checks what the previous record was like and then only updates if that record's field(s) were different (did this with If ( (field_1 = field_2) and (field_3 = field_4)..... ) End If ).

 

For instance, if someone changes the name of a product it should create a history record. However, if they click into the name field, and then click out it shouldn't create one.

 

Am fairly new to Filemaker (around 3 weeks into learning) so appologies if this is a basic question. I could turn this into a button, and if there was no other way to do it I'll create an edit option to go to a specific layout.

 

Any help would be great

Please update your profile to reflect the Platform, OS, FileMaker Skill Level and FileMaker version. Click MY PROFILE for a quick link.

Done so

Look here:

 

 

FieldChangeMonitor_eos.fmp12.zip

@ eos

 

... but if you drag from field2 to field1...

 

The attached file ( a modified version of eos's file ) takes in account the drag & drop problem.

FieldChanges.zip

Almost exactly what I needed!

Though this method doesn't seem to work with value lists. Any idea why?

Post your file with the not working value list.

Didn't look at the file, but what about using two timestamp fields, one auto-entered and the other scripted. An onRecordCommit would check to see if the two match and if not, create a history record and update the scripted one. If you want it field-based, you'll need another field that tracks changes locally ( google UltraLog).

@Raybaudi - The Value list works, what doesn't work is the Logging from the example files above when the value in the value list is changed.

 

@David - The system proposed above uses a global variable that sets the value when the it's entered to the Object Contents, and when it exits it checks what's now in the contents against the variable, and if they're different then it will create a history record. Now this works perfectly for fields that are text based, but seems to have a problem when it comes up against a value list. However when you change a value in the value list, the value that was in the table changes, so I'm not sure if it's simply because it's a pop-up menu and not an edit box, or whether there's something else that's causing a problem.

@Raybaudi - The Value list works, what doesn't work is the Logging from the example files above when the value in the value list is changed.

 I can't see any malfunction... can you give me an example, using the file attached ?

FieldChanges.zip

Yeah, you're going to have problems with triggering on entry field triggers when using pop up menus as well as drag and drop.

@Raybaudi: Looks like your drop downs work perfectly, however it won't even register a change with pop-up menus like it's denying editting of the field. And this is on your file.

@David: Yup, looks like I'm either gunna have to use drop-down or figure out an entirely different way of doing it. Looks like it's to do with Get ( ActiveFieldContents ) not registering the content of a pop-up menu. Edit: Looking at this further, it seems that the "OnObjectEnter" Script trigger is only triggering AFTER the change on the pop up list. So it's processing it right, but the result is already changed by the time it runs the script.

Thanks to the guys that have helped by providing example stuff though. Gives me something to go on

Edit:

I've just tried using the function on iPad and it works perfectly, but on desktop it doesn't. I'm most confused right about now.

Here's another stab at it. Not tested on FM Go.

FieldChanges_eos2.fmp12.zip

@eos Looks like that's got it.

For those that don't open the file, changing the script trigger to OnModify instead of OnEnter for value lists will pick up the original value and be able to compare it to the OnExit value. Doesn't seem to make sense to me why that would be the case but I guess it works.

A minor problem would be if a user changes the value of a field with a pop-up menu, then chooses another. You'll get an inaccurate "previous value". Though I'm not sure if that matters, since you should have an accurate "current value" from the *previous* audit record.

 

Another problem is the drag and drop doesn't trigger OnObjectExit on the target.

 

Still, might be good enough for what you need.