Script to warn before replacing container contents

[Dunedin_fm]

Dear Experts,

I was hoping someone might be able to help me write a script to warn users before they replace a file in a container please?

I have the following script that is triggered on modification of the container (screen shot attached).  It works partially only as it also fires on dropping a file in an empty container.  

Any suggestions would be really appreciated.

Many thanks,

 

[Steve Martino]

For starters you don’t need steps 8 & 10.

i would try testing for not isempty(trial::container).  Pseudo script, untested:

If [not isempty(trial::container)]

   Show Custom Dialog...]

      If [Get(LastMessageChoice)=2//Don’t Replace Container

         Revert Record

      Else

         Commit Record...

      End If

End If

 

The 'Else' and 'Commit' May not be needed unless you actually want/need to commit the record at that moment.

Committing the record may actually trip layout triggers.

Also you don’t say why the script doesn’t work or how the container is modified.  Here’s a help link about what does and doesn’t trip triggers.

https://fmhelp.filemaker.com/help/16/fmp/en/#page/FMP_Help%2Factions-dont-activate-triggers.html%23

 

 

[Dunedin_fm]

HI, thanks for getting back to me.

The script, as I posted, seems to work as long as you use 'insert file' or 'insert pic' to place a file in the container.  However, if the container is empty to begin with, it still asks if you want to replace contents, where I was wanting it not to.

The script does not seems to work if you drag & drop a file in the container: the dialog shows up but the contents get replaced regardless of the choice made.

I tried your suggestion but it behaves similarly.

Kind Regards

[Steve Martino]

Can you post a sample file exhibiting the behavior?

[David Head]

Have a read of this useful article: https://www.geistinteractive.com/2018/01/08/filemaker-drag-drop-gotchas/

 

Quote

 

The script trigger sequence, breaks down in a drag/drop scenario:

• onObjectModify does run, but it runs after the record has already been committed (or the record has been closed).
• The rest of the triggers do not run at all, no matter if they were meant to be a pre- or a post- trigger.

 

Cheers, David

[Dunedin_fm]

Thank you David and Steve.  I think that would explain the problem.  You must have had clients ask for a similar solution?  Have you any other work arounds?

 

Kind Regards

 

[AHunter3]

If you're in love with drag-n-drop and you really want to go with script triggers here, I think you should consider a global container field as a temporary holding tank into which to drag things, and attach the script trigger to that, with the real container field (and the replacement of the contents thereof) being thereby easier to script.