script trigger doesn't get invoked if value doesn't change

[jjjjp]

I want to be able to set a boolean field, IsModifying, to indicate whether certain other fields in the record, say A, B, and C, are in the process of being modified. (If they are, I will program my scripts to block certain other operations on the record.) For each of the fields A, B, and C, I set up two script triggers, one to set IsModifying to 1 OnObjectEnter, and the other to set it to "" OnObjectSave. However, it appears that the closing script trigger gets invoked only if the value changed. Exact same problem if I use the trigger OnObjectValidate instead. So if a user enters the field A but in the end doesn't modify its value, IsModifying stays set to 1 after the user is done modifying the field rather than being reset to "".

Maybe the solution is obvious, but I can't see a way around this problem.

Thanks in advance for any help.

[Raybaudi]

Hi

why not OnObjectExit ?

IsModifying.zip

[jjjjp]

That worked. Why, you ask, not OnObjectExit? Because the mini display window only showed only up to OnObjectSave, and I didn't notice the scroll bar! OnObjectSave sounded very final to me, so I assumed it was the last in the list. Sorry for the trouble over what was really a simple problem.

[comment]

I am not sure what exactly you are trying to achieve here. Entering a field is not "modifying" in Filemaker. Conversely, if a field value has been modified but the record is not yet committed, the field can be viewed as "being modified" even if it's not active - in the sense that it will revert to the original value if the record is not committed.

[jjjjp]

I would like, for example, to have more control of what happens if another user tries to delete the same record. In my current setup, when a user deletes a record a script is invoked that (among other things) changes layout (from a portal to the main table layout) and checks some conditions, and I find that some screwy things happen at least as far as what the user sees (unexpected layouts flashing on the screen, a query asking if the user wants to go ahead with the delete prior to being told he/she can't). In short, I am experimenting with taking back some of the control from Filemaker, even if the end result may be the same (e.g., a deletion successfully blocked).

So when a user goes into a field, deletions will be blocked by my script before Filemaker gets a chance to do the same. True, the user might not end up changing the field, but I don't see temporarily blocking deletions as a big issue. The user can still modify other fields for the record, and I continue to rely on Filemaker to check for multiple users trying to modify the same field. Note that I commit the record (via the script called by the script trigger) as soon as the user leaves the field. I hope that isn't a mistake, but I see no need to allow for the possibility of reversion later on.

I am at the early stages of implementing this change, so let me know if you still thing I am getting off on the wrong foot.

Thanks,

Jerry

[Vaughan]

I would like, for example, to have more control of what happens if another user tries to delete the same record... I am experimenting with taking back some of the control from Filemaker.

If I may be frank, this is a waste of time. FileMaker has solved the issue of record locking in the multi-user environment decades ago. Anything you do to "take control" from FMP will provide the users with LESS usability, not more.*

Spend time getting the data structures correct. Spend time getting the user interface better by watching real people work with your database. Be amazed at the incredible things they'll do with it that you never expected. Don't spend time re-inventing things that aren't broken.

* I have just spend several weeks fixing a solution where the developer had created a "save" mechanism for case notes that resulted in the users work being lost if they forgot to click the special "save" button before closing the window (their data entry went into a global field and a script set the data into the real field). The users cannot be blamed for this: the default behaviour for FMP is for data to be saved on record commit. I stripped all the fancy scripting out and returned the default behaviour (users entered the data into the real field) and they are now very happy customers, no lost work in weeks. The pity for them is they they paid for this guy to put it in, then paid me to take it all out.

[Vaughan]

...what happens if another user tries to delete the same record.

There are already ways to do this that do not involve defeating the default behaviour. Use error trapping.

Set Error Capture [ on ]

Delete Record/Request []

Set Variable [ $error ; Get( lasterror ) ]

Set Error Capture [ off ]

If [ $error = 0 ]

#no error, record was deleted

Else

#error deleting record

End If

When editing records, use the Open Record script step to see if the record is locked.

[Vaughan]

Note that I commit the record (via the script called by the script trigger) as soon as the user leaves the field. I hope that isn't a mistake...

It's quite possible that immediately after the commit another user could get the record lock for themselves. Every time you commit the record you're saying "OK I've done with it, somebody else can have a turn now."

[jjjjp]

I'm actually quite relieved to hear that there is ever any need to second-guess Filemaker's ability to manage record locking. I am beginning to see the possibilities inherent in the Open Record and the Capture Error steps, and I will now think more carefully and strategically about how and where I open and commit records.

Thanks for setting me straight.