Leaderboard

Yes. Every script has its own parameter that must be passed to it explicitly when the script is called. To pass its own parameter to a subscript, the calling script would need to do: Perform Script [ “abc”; Parameter: Get ( ScriptParameter ) ] Keep in mind that a subscript does not "know" it's a subscript. It runs independently and does not inherit anything from the calling script.

This is a little too much to take in all at once. Consider simplifying the issue and/or breaking it up to individual points. Speaking in general, the script parameter remains constant throughout the life of the script, while a script variable can be defined and redefined at any point. If you want to export a file using a variable as the file's name, and the file's name is supposed to contain the count of exported records, then of course you will want to define that variable as close to the export as possible and not before any event that can modify the current found set. HTH.

In MBS FileMaker Plugin 15.3 we have a Format button on macOS for the data viewer's detail view. If the data is XML or JSON, we can use the format and colorize functions: JSON.Format & JSON.Colorize, XML.Format & XML.Colorize. Let's say you have some variables in the data viewer with XML or JSON content. When you double click the text, you get a new window showing the detail. Here we find the Format button added by MBS Plugin. Press the button and it will format the content: If we get a parse error or the content is not XML/JSON, we beep. If you click OK, the formatted text is stored in the variable. If you press cancel, the unformatted text stays in the variable. Please try the feature and let us know what you think. Available for macOS in MBS FileMaker Plugin 15.3.

Just to comment on this line of thinking: “I have a script that I would like to use in multiple "similar" situations”. Be aware that what seems economical can lead to highly conditional scripts that are difficult to maintain or change without risk. Separate scripts without much indirection or abstraction are more easy to maintain and troubleshoot. Consider the trade off you’re making.

You cannot use a variable to specify the field in the Edit Find Request window. But a find request can also be constructed through setting fields - and then you can use the script parameter to select which field to use, similar to what we discussed only recently here: https://fmforums.com/topic/110860-script-problem-remove-container-file-from-a-record-trying-to-transition-to-json-to-pass-multiple-parameters/#findComment-494081

As you can see from the release notes, folders for custom functions have been implemented: https://help.claris.com/en/pro-release-notes/content/index.html

https://www.fmcomparison.com

There are various tools that can compare DDRs such as: BaseElements https://baseelements.com/ CrossCheck http://www.fm-crosscheck.com FMDiff http://fmdiff.com/ FMperception https://www.fmperception.com/ InspectorPro https://www.beezwax.net/products/inspectorpro-8 I have no recommendation to make since I don't use any of them. You can also use general tools for comparing XML documents (either DDR or the output of Save a Copy as XML). The result may be more difficult to read but it could be all you need for a one-time task such as you describe. Oh, and for fields only you could simply compare the results of ExecuteSQL() querying the FileMaker_BaseTableFields table.

I don't know if that's a good analogy to your situation. Anyway the answer here is yes, at least WRT interference. They would simply login as different users and their privilege set would deny them access to any records other than those tagged by their account name. Then it's up to the developer to prevent situations where a bunch of records labeled <<no access>> would crop up - such as replacing the Show All Records command with a bogus find (any find will automatically omit records for which the user has no access). And there may be other details to consider e.g. serial numbering of records. Maybe not: https://support.claris.com/s/article/New-FileMaker-data-migration-tool?language=en_US

Actually, it's quite the opposite: you would have a List layout to show a bunch of records (typically non-editable). Then you use a popover or a card window to drill into a specific record for more details and/or editing. It's functionally similar to list-detail layout but you have more space to work with, since the detail temporarily conceals the list.

Yes, that's exactly what I meant. You are not alone in that wish, it's been often suggested (usually as a type of a layout part). As a side note: while I often switch between form and table view in solutions for my own use, I would almost always create separate layouts in solutions designed for others. So there would be a button for "detailed view" on the list layout and a "back to list" button on the form layout. Also keep in mind the possibilities offered by list-detail layouts, popovers and card windows.

When I read this, I was taken aback: I thought surely a button cannot override the layout setup and allow access to a view which the developer has disabled?? But you are right, it does do exactly that. I consider this a bug. I think you have no choice other than to customize the bar for its specific layout. It's not like we have the option to share objects across layouts anyway.

That's not going to work. Exactly. A button activates only by tabbing into it. Again, your hunch is correct. You don't need to add the selected button's object name to the script parameter. In fact, the buttons do not need to have object names at all (at least not for this). You only need to add a recognizable value to the script parameter of each button. It could be as simple as 1, 2 and 3 or perhaps something more explicit - say "current", "found" and "all". Then extract this value from the script parameter and use it to branch your script.

From what I can see the problem is that you are passing the container field's value instead of its name. Try defining the script parameter along the lines of = JSONSetElement ( "" ; [ "container_field_name" ; GetFieldName ( document::document_file ) ; JSONString ] ; [ "container_file_name" ; document::document_filename ; JSONString ] ) You could also get by with: JSONSetElement ( "" ; [ "container_field_name" ; "document::document_file" ; JSONString ] ; [ "container_file_name" ; document::document_filename ; JSONString ] ) but this would break if you renamed the container field.

Just a random thought: Whether a field is optimized for static or interactive content is a matter of formatting the specific instance of the field on a specific layout. You could have two separate layouts showing the same field optimized differently. Or two different instances of the same field on different panels of a tab/slide control. Or even just hiding one of them conditionally.

Not really. Your formula for constructing the JSON is correct and if the referenced field contains the text "Active" you should be getting the result you expect. Is it possible that the two tests were performed from different records?