Jump to content

Detect field modification before Commit

This topic is 5697 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Is there a function or some other technique to allow a script to detect whether there have been any modifications made to the data on a layout, before that data is committed?

I don't need to know what field(s) were changed, or how many changes there were. Just a boolean.

I have a basic Invoice/LineItems layout and I would like to alert the user ("Changes made - discard or save?") if he attempts to navigate elsewhere after modifying the invoice. Obviously I don't want to put up the alert when he hasn't made any changes.



Edited by Guest
add 2nd paragraph
Link to comment
Share on other sites

It's pretty close, the Get(RecordOpenState) function.

One problem: it doesn't distinguish between a New+Unused record (a new record into which nothing has yet been typed, let alone committed), and a New+TypedInto record (a new record into which something has been typed but which has not yet been committed).

In my interface, I require the user to always explicitly save or discard any changes she makes to a record. [This is because it gives her the heebie-jeebies not to perform some action to save/commit/check-back-in her work!] If she forgets to do this before, say, closing the edit window or clicking on the "Next record" button, I want to trigger an alert telling her that she has some "pending" changes, and does she wish to Save or Discard them? Get(RecordOpenState) does not appear to discriminate between a virginal and non-virginal New record.

It would also be very nice to be able to visually activate or deactivate the Save and Discard buttons conditionally upon whether there have been any saveable or discardable changes, but I'm not sure the interface can be made this dynamic without Script Triggers or something...

I hope that clarifies the problem I'm trying to solve.

Link to comment
Share on other sites


I looked at your file but I don't understand what I should be paying attention to...

Fields 1-5 are simple text fields. the_first_validation and the_second_validation appear to be important - both are validated by calculation; the first is valid if AT LEAST ONE of f1-f5 are non-null; the second is valid if ALL of f1-f5 are non-null. Additionally, the second allows override.

AH! I see - you're saying that, to detect whether a new record has pending input to commit, use hidden fields with custom validation, and validate with a calculation. The calculation does the work of examining the real fields to see that they're properly filled in. I'll try it. Hopefully, functions such as Count(field [;...]) return useful results even before the record is committed.

Link to comment
Share on other sites

This topic is 5697 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Create New...

Important Information

By using this site, you agree to our Terms of Use.