comment

It's not exactly a loop. I meant keep a counter in a global field or variable, and when the counter gets to 60, do the other thing and reset the counter - something like (pseudocode, untested): Perform Script [ "Script A" ] Set Variable [ $$OnTimerCounter ; Valus: $$OnTimerCounter + 1 ] If [ $$OnTimerCounter = 60 ] Perform Script [ "Script B" ] Set Variable [ $$OnTimerCounter ; 0 ] End If Install OnTimer Script ["This Script"; Interval: 15] -- P.S.. Javascript is not Java. Two completely different things. And using Javascript in a web viewer is often convenient, esp. for tasks like this that involve a "live" ticking clock - see, for example: https://fmforums.com/topic/71934-calculating-elapsed-time-realtime/?do=findComment&comment=340205 From: https://www.smashingmagazine.com/2009/07/misunderstanding-markup-xhtml-2-comic-strip/

Two possible solutions come to mind: 1. Have your OnTimer script do one thing every 15 seconds, and two things every 15 minutes (or every 60th runtime). 2. Use a web viewer for showing the current dance (will require some Javascript work).

This is not going to be simple, because Filemaker can divide text only to paragraphs (values) and words. In your example, the substring: https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmypcsecurity.webrootanywhere.com%2Funsubscribe.aspx%3FT%3Dasdffsdf34228e3b-77d9-4eb2-8132-778fd4dea454%26UEM%3Dsupport%40madso.uk&data=02%7C01%7Cuser@company.com%7Casd29c4c0901c808d673d792d0%7C7a80fada51274aa9aaedca692e314d1d%7C1%xxx68237670672dddata=0YhXOxZRHF6%2Fls6fY%2BA4za%2BvsGo6dPBtWMQhVQZo%2ByE%3D&reserved=0 is actually 32 separate words, the way Filemaker sees it. So you need to make up your own division - probably by looking for spaces and returns as the only separators to consider. And of course, this must be a recursive process, taking each "token" in turn and examining it for length. In the attached demo, I used a looping script (with 2 loops, one for paragraphs and one for tokens separated by spaces). To make this a calculation, you would need to replicate the same logic using a custom function (or functions). ShortenLongStrings.fmp12

Then I am afraid I don't understand what you mean by "string". Wy don't you provide an example or two of what's in the field and what you would like to see as the result.

How about: Left ( YourField ; 20 )

Have a look at the attached file. It has two report layouts, one with a trailing grand summary and one without. If you sort the records and enter Preview mode, you should see this: in the layout without a trailing grand summary and this: in the layout with the grand summary part. BlankSpaceColor.fmp12

Try adding a trailing grand summary part to your layout. Give it the same fill color as your footer and reduce its height to minimum. -- P.S. I am unable to reproduce the problem as shown in your screenshot. For me, the blank space above the footer is filled with the fill color of the part above the footer.

I am not aware of any method that would create layout objects such as buttons dynamically. The most you can do is pre-create as many buttons as you could possibly need, and hide the unused ones. If you use a button bar, you can use calculated labels as well as hide the surplus segments. Another option is to place the buttons in a portal. A portal can be de-duped - and if you have a TO of Courses behind ASSIGNMENT_COURSE, then you can make the portal show the records from there and have it show a row for each unique course only without any additional effort .

I am afraid it's not as simple as you may think. If you want users to see a a list of options, you must have an object to display these options for the user to select from. Filemaker does have a built-in auto-complete feature, but it won't work like you describe. You could use a portal, but IMHO it is easier to open a new window than to have a portal appear below a field and disappear after a selection has been made (although it can be done).

Why don't you open a new window showing a list of all elements, along with a global field where the users can enter their description. Then, as they type, reduce the number of shown elements by performing a find.

Why can't the calculation be stored?

The simplest method would be to perform a find in the Users table while entering criteria in fields of both tables. Then use the Get (FoundCount) function to retrieve the number. This is of course assuming you do have a relationship based on matching UserID. To get the same number by counting related records would be more complex. You would need a group of three table occurrences, something like: AnyTable::gMinStartDate ≤ Acitivities::StartDate and then: Acitivities::UserID = Users 2::UserID AND Acitivities::gMinRegistrationDate ≤ Users 2::RegistrationDate With this in place, you can count the related records from Users 2 (from the context of AnyTable) to get the same number as before. Another option worth mentioning here is the ExecuteSQL() function.

Yes, it's possible - but I would be reluctant to go that way, because the comparison is done in text domain. If your date format is MM/DD/YYYY, then comparing an entry of "5/5/2019" (which is a valid entry into a date field that Filemaker will accept) to the result of Date ( 5 ; 5 ; 2019 ) will fail, because "5/5/2019" is not equal to "05/05/2019". You may protect yourself (at least as far as user data entry is concerned) by auto-entering GetAsDate ( Self ) into the date field. In any case, the calculation would be = not IsEmpty ( FilterValues ( $$_ProposedDate ; ValueListItems ( "" ; "YourValueList" ) ) ) Another option is to use a relationship matching a global date field against your date field, and test for the existence of related records. All that said, there's no reason why ExecuteSQL() couldn't work just as well. Hopefully, you are using it in a script, not in a calculation field. (And if so, a script variable should be sufficient.)

No, I meant using an actual slide control object they can use to swipe left and right. But all the swipe would do is trigger a script to bump a global field/variable up or down. Or, if you want to make it more fancy, it would also slide to the left/right panel to show some motion, then cut right back to the middle (much like what @OlgerDiekstra described).

Every layout is associated with a table occurrence, which in turn belongs to a base table. When you create a new record, you create a record in the current layout's table - and only in the current layout's table. If you want to create a pair of records, one in each table, you'd probably want to script the process. Or define the relationship between the two tables to allow creation of related records. That way you can create the "other" record by filling one of its fields. How about giving your tables meaningful names and explaining the purpose behind this exercise? It's much easier to help with the "how" when one knows the "why".