Jump to content
View in the app

A better way to browse. Learn more.

FMForums.com

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Featured Replies

Hopefully there is a simple solution to this that I'm overlooking!!

I've got a multitude of scripts that are quite lengthy (read: they take 3-30secs to run), and I'm heavily using multiple windows with different layouts. Here's the problem, while a script is running, if a user clicks on another window (with a different layout of course) while a script is running it continues operating, but on the window that was just clicked -- often with disastrous results.

Is there any way to prevent the user from being able to interfere with a script while its running?

Thanks for everyone's time & knowledge on this!

Running on Mac OS X 10.4, FM Adv 8.5

Edited by Guest

My take at it is that such scripting seems to be due a relational flaw, but take a look at:

http://www.filemaker.com/help/Script-Steps13.html

But then again, how come your scripting are sensitive to which layout the user chooses to get to? There are alternatives to copy/paste, which for most reasons are relational unhealthy but always are bad programmers habits! Secondly do there exist looped alternatives to scripted replaces.

--sd

You might also want to use the "Freeze Window" script step:

1) The user can't interact with anything

2) The script proceeds a lot faster if layouts don't have to be loaded at each step.

My take at it is that such scripting seems to be due a relational flaw

I don't think that is a fair conclusion. A script like:

Go to Layout [ xyz ]

Loop

Set Field [xyz::Somefield ; < a complex calculation > ]

Go to Record [Next; Exit after last]

End Loop

does not seem to exhibit a relational flaw, IMHO. Still, it wouldn't do for the script to switch to another window and start looping there.

This problem has come up before and I don't know of a good solution for it. Neither Allow User Abort[Off] not Freeze Window can assure this will not happen.

Re-selecting the window before any step that is context-sensitive might be in order, but it is - at least theoretically - possible to make the switch at the precise moment between selecting the correct window and the rest of the script.

My freeze window suggestion was only a general thing -- I suppose the can't interact with anything may've been an overstatement though.

I only suggested it because the OP said their script runs for 30 seconds which is quite unusual unless you are running either an extremely complicated script or a fairly simple script that is either looping or swapping layouts without the window frozen.

I don't know what's usual and what's not. I believe that until proven otherwise, posters should be presumed to know what they're doing.

Fair enough, i can respect that i guess.

posters should be presumed to know what they're doing

I would guess you're pretty alone here, the rest of us are constantly breathtaken by yet niftier ways to acomplish things, that we can't be absolutly sure we nailed a problem more than 80% !!!! We have perhaps a sense of the longitude and altitude and the approximate direction ...but knowing what we're doing NO! We can only envy you certainty....

--sd

Go to Layout [ xyz ]

Loop

Set Field [xyz::Somefield ; < a complex calculation > ]

Go to Record [Next; Exit after last]

End Loop

I came brainstormingly to think of this:

http://www.sumware.net/robfm/savingfoundsets.php

...and a $variable to control the position in the found set and when the final record is reached, instead of the "Next; Exit after last" in Go to Record[

--sd

We can only envy you certainty....

It's not a certainty, only a presumption. I think the problem presented here is a real one, and not a by-product of a flaw, as your initial response suggests.

It may be possible to avoid the problem, or at least to minimize it - but it requires recognizing that the problem exists in the first place.

  • Author

Everyone, Thanks for all of the great insight and information! I had a feeling that I'm probably going to need to insert Goto Window & Goto Layout script steps to ensure that the script is operating on the correct window. ...was just trying to minimize the number of steps in my scripts to make them run as efficiently as possible.

I had tried the Abort Off and Freeze Window and it doesn't seem to fix the problem.

comment -- I think you're right - this really does seem to be a flaw with FM's scripting system. My need is how to make this more bullet proof for unexperienced click happy end users using built FM apps.

Søren Dyhr -- great link on GTRR! I've never thought of that method...

I'm currently HEAVILY using GTRRs where I'm putting the results into new windows -- doing my operations and then closing and reselecting the original windows. I'm open to any feedback on good vs bad on using this method.

Thanks!

Ryan

I'm currently HEAVILY using GTRRs where I'm putting the results into new windows -- doing my operations and then closing and reselecting the original windows. I'm open to any feedback on good vs bad on using this method.

I do all operations in one window -- On Windows you kind of have to if you want the solution to look decent.

Create an account or sign in to comment

Important Information

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

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.