Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.databases.filemaker > #1937 > unrolled thread

Protect Container, best praxis

Back to article view | Back to comp.databases.filemaker

Contents

  Protect Container, best praxis clkaufmann@gmx.ch (Christoph Kaufmann) - 2014-12-11 17:07 +0100
    Re: Protect Container, best praxis Jeremy Bante <jeremy.bante@gmail.com> - 2014-12-11 13:59 -0800
      Re: Protect Container, best praxis Helpful Harry <HelpfulHarry@BusyWorking.com> - 2014-12-12 13:37 +1300
        Re: Protect Container, best praxis clkaufmann@gmx.ch (Christoph Kaufmann) - 2014-12-13 14:50 +0100
      Re: Protect Container, best praxis clkaufmann@gmx.ch (Christoph Kaufmann) - 2014-12-13 09:37 +0100

#1937 — Protect Container, best praxis

FMP 13: using drag and drop to fill a container field (external
storage/secure) is all too easy: if a file is in the container, it gets
replaced and filemaker does not even prompt me for confirmation, even if
it set not to save changes automatically.

So how do we protect existing files from accidental overwriting?

Validation? Comes in too late.

Trigger On Objekt Modify? But if I ask what's already in the field, I
get the new file anyway, won't I?

Use Privileges to lock the record?

Give the user a global Container field to play with?

More ideas?

-- 
Christoph Kaufmann
http://clk.ch

[toc] | [next] | [standalone]

#1938

On Thursday, December 11, 2014 8:07:57 AM UTC-8, Christoph Kaufmann wrote:

> Give the user a global Container field to play with?

Exactly. Make the actual data field non-enterable, and format the global container field to be invisible, then your OnObjectModify scripting can run the checks you want before (if choosing to accept the new file) copying the global field contents into the data field and clearing the global.

[toc] | [prev] | [next] | [standalone]

#1939

In article <fec4cea3-1b30-4a41-814d-5083774ad219@googlegroups.com>,
Jeremy Bante <jeremy.bante@gmail.com> wrote:
> On Thursday, December 11, 2014 8:07:57 AM UTC-8, Christoph Kaufmann wrote:
> >
> > Give the user a global Container field to play with?
> 
> Exactly. Make the actual data field non-enterable, and format the global
> container field to be invisible, then your OnObjectModify scripting can run
> the checks you want before (if choosing to accept the new file) copying the
> global field contents into the data field and clearing the global.

Or, depending on how the database is used, you could just disable user
access to the Container field and have an "Insert" button which runs a
script to do the necessary checks and import the object.

Helpful Harry  :o)

[toc] | [prev] | [next] | [standalone]

#1941

Helpful Harry <HelpfulHarry@BusyWorking.com> wrote:

> Or, depending on how the database is used, 

That's the pont.

> you could just disable user
> access to the Container field and have an "Insert" button which runs a
> script to do the necessary checks and import the object.

And the mechanism is already there, because that's how we did it before
Filemaker introduced drag and drop for container fields - new feature,
new problems, and with great power comes and a'that :-)

-- 
Christoph Kaufmann
http://clk.ch

[toc] | [prev] | [next] | [standalone]

#1940

Jeremy Bante <jeremy.bante@gmail.com> wrote:

> Make the actual data field non-enterable, and format the global
> container field to be invisible, then your OnObjectModify scripting can
> run the checks

Thanks - after I found the drag and drop bypasses both Filemaker's
record change prompts and OnObjectEnter and OnObjektExit triggers, I
didn't even check OnObjectModify.

Works like charm.

-- 
Christoph Kaufmann
http://clk.ch

[toc] | [prev] | [standalone]

Back to top | Article view | comp.databases.filemaker

csiph-web