We use a button bar for all of our container interactions and lock the user out of interacting with the container field on the layout directly. This allows us to script when something is added, when it is changed, and when it is removed via buttons.
In your case, doing the same would allow you to set other fields via scripts with the Get(CurrentTimeStamp) of when that action was performed. you could even create a full-blown transaction log that showed all historical changes (and retained a history of previous container data even).
Sky's the limit really on this type of thing, you just need to control how the user interacts with the containers.
BTW, GetContainerAttribute() will only return metadata from the file information itself, it does NOT return the modification timestamp of when that data was modified in filemaker. EG if a photo was created at ___ time, and edited by photoshop at ___ time, then you would get THOSE timestamps using that function, NOT whenever it was added to filemaker.
I'm relatively new to the developing side of FMP - would you be able to explain a bit what you mean by a button bar and how I may go about setting it up in the way you've described? Do I create a button that performs the GetCurrent(Timestamp) and leave it at that? Where does it propagate upon clicking the button?
If I were to go about creating the log, is that overly complex to do for someone who has basic understanding of the general functions?
The only issue I can foresee with this method, is that the pdfs are used by our employees out in the warehouse (Im office admin) - so they need to interact with them (in the sense they click, download to their computer and proceed with their work). Would that not be an option with your method?
If they can still have access to the documents, your method otherwise sounds like the way I should go.
Thank you very much!
The easiest way I can think of is to script all of the interactions your users would have with the container field (adding a file, downloading, etc.). That way you can have your script that adds (or replaces) a file in the container also update a "File Modified" field. This is instead of allowing your users to right-click on the container and interact with it natively. One caveat is that you won't be able to tell if the document itself is different, in that the "doc modified" field would still be updated if a user simply replaced the document with itself.
How you set up access to these scripts has nearly endless possibilities- via the script menu, via buttons around your container field, etc.
I put together this demo file for you to show you since it's easier than explaining. Take that apart and take a look at how each portion works. If you have questions let us know.
ContainerDemo.fmp12.zip 173.6 K
1 of 1 people found this helpful
I prefer a schema level approach so no matter where the container field is used, the modification timestamp will update without attaching the scripting. Whether you use scripting to insert container data or perform the task manually using the menus, this method will still work.
All you have do is define an auto-enter calculation on your timestamp field that keeps track of the last time the container was modified. Use the following formula:
Make sure to uncheck the auto-enter option to "do not replace existing value of field (if any)".
1 of 1 people found this helpful
Jaymo's approach is easiest and solves the stated problem, but it needs to be tweaked to avoid deleting the timestamp if the file is cleared. Try this:
If ( container or 1=1 ; Get ( CurrentTimestamp ) )
Turn off "Do not evaluate if all referenced fields are empty" in the calculation dialog.
Turn off "Do not replace existing value of field (if any)." in the field options.
The "or 1=1" ensures that the condition always evaluates TRUE. The reason we also include the reference to the container field is so that the calculation updates when the container is modified. Merely "mentioning" the field in the formula, even though it has no affect on the result, is what triggers the auto-update to take place whenever that field is modified.
To clarify Bergsten's other trials, the reason the modification options are greyed out in the field definition for the container is that containers store files, not timestamps. It would be like trying to auto-enter a date into a time field or an essay into a number field. Secondly, GetContainerAttribute can get any of a set list of attributes that a container might have. These are listed in help. Modified timestamp is not one of those attributes. But you were on the right track in that you need a separate field for every timestamp to track the modification timestamp.
If you want to calculate all the time, avoiding If() would be clear for reading.
Let ( dummy = container ; Get ( CurrentTimestamp ) )
or specific function (but need the calculation be quoted as text)
Evaluate ( "Get ( CurrentTimestamp )" ; container )