works like a charm here, but:
- it does not return modified related fields (by design).
- it does not work on a new record. Those fields are not "modified" in the true sense.
got the first bit
second bit - obvious when you think about it
created a second record, added some data
went back to first
edited record, when tabbed out script runs but does not give a resutl for function - either in script or dataviewer.
Restarted too just to be doubly sure
but still no result
works like a charm here. I can see them in the data viewer. You have to have exited the field before it registers as being modified, so I guess it only updates after the "onModify" event?
Got it now.
Was trying to do something with a single record virtual record, but of course I need to explicitly commit the record on field validate to trigger the function.
For our amusement here is a modfied version which saves completed or attempted edits but reverts the record if any field contains a forbidden value ("bruce" in the example)
ModifiedFields.fmp12.zip 69.9 K
John, when FMPv13 was released, I stumbled across and experimented (very briefly) with this new feature.
I found text fields and calculation (text result) fields were listed in the Get ( ModifedFields ) result but modifications to number, date and time fields did not appear in the Get ( ModifiedFields) result.
I did not spend anytime troubleshooting because there were too many other new features to experience. Are you modifying a Text field?
It was a text field
but my error was trying to get the result of the get function in the script after being triggered, rather than sending it to the script as a parameter when validated or saved.
I did not want to be using on record save, as this specific case uses a single record layout with several copies of the field which get hidden when required so it can be used a multipurpose input (taking text or a date or a number...) but I wanted to know if in one case a default value had been over-ridden
It does now work as changing the field value by using a scripted button and importing the default value from an ExecuteSQL query does not trigger the onfieldsave but typing in manually does
wimdecorte a écrit:
[…]- it does not work on a new record. Those fields are not "modified" in the true sense.[…]
I am just struggling with FMI about this particular point and I am surprised you find it natural. Actually, they just promise to update documentation because the help article is not clear at all about this specific point.
If I perfectly can understand your opinion about the "semantic" aspect, i disagree in practice aspect.
But i am "open mind" , so : in which case actual behavior could be better than if this function worked over both open record states ???
Thank you so much for your help !
PS : Sorry for my terrible english