macOS 10.13.6. FileMaker Pro Advanced 16.0.6.600.

In a solution "A" on my computer, I created a script as follows, to remove any non (field) default formatting in effect on a selected field. I used this method: "If no field is specified and a field is selected in Browse mode or Find mode, that field is used."

The script works as expected:

Set Field By Name [ TextFormatRemove ( get ( ActiveFieldContents ) ) ]

During testing, I've saved the script in solution "A", and even quit FileMaker and reopened the two solutions.

When I copy the script and paste it into solution "B", the script changes, adding Get ( ActiveFieldName ) ; to the specified field (which has no value in "A"):

Set Field By Name [ Get ( ActiveFieldName ) ; TextFormatRemove ( get ( ActiveFieldContents ) ) ]

Is this expected behavior? Note: when I click Specify Target Field in "A", Get ( ActiveFieldName ) appears, so I'm thinking that when leaving that blank, as I did originally, that Get ( ActiveFieldName ) is actually in effect, even though it does not show up in the script step. (I *was* able to modify it to how it was written in "A" once in "B".)

Edited January 16, 20206 yr by ken_s2007

Yes, it is expected behavior. Under the hood, FM tracks most things by ID and not by name,  So when you paste code (fields, scripts,...) and it has references to other objects then FM will match them up by ID, which may or may not be the field or script you intended.

What you wrote makes total sense in general, but it piqued my curiosity about this particular script step.

Get ( ActiveFieldName ) returns the name of the field that has focus, and Get ( ActiveFieldContent ) returns the contents of the field that has the focus.

My hunch is that when this script step completes execution, that no ID nor content is stored in relation to the script step. Thus (IMO) when this generic script is copied and pasted into another file, it should remain exactly as written, for consistency.

If, however, data specific to the last execution of the script *is* stored 'behind the scenes' and attached to that script somehow, then I could see how that could change how script steps are formed when copied and pasted, although not for this particular script step.

It appears that leaving the (specified) target field blank is simply shorthand for ( GetActiveFieldName ), and that the blank value in the target field should be honored after the script is copied and pasted, for consistency. Fortunately, there is no behavior change that I can see when using ( GetActiveFieldName ), so it is a somewhat minor point.

But if there's more to it than that, I'd love to know. Thanks.

Edited January 16, 20206 yr by ken_s2007

I wasn't able to reproduce the claimed behavior (using v.18). Copying a script that contains a Set Field By Name [] step with no target field specified and pasting it into another file results in a Set Field By Name [] step with no target field specified - exactly like in the source file.

BTW, if you don't want to specify the  target field name, why not simply use the Set Field [] script step.

 

Edited January 17, 20206 yr by comment

On 1/17/2020 at 1:42 PM, comment said:

BTW, if you don't want to specify the  target field name, why not simply use the Set Field [] script step.

That was my initial attempt, but when selecting "Specify target field", then clicking "Specify...", I did not see a way to programmatically set the field name.

Good to know it works in v.18, thanks.

4 minutes ago, ken_s2007 said:

I did not see a way to programmatically set the field name.

I thought you did not want to set the field name, but let the step operate on the currently selected field? Just like the Set Field By Name[] script step, the Set Field[] step too will use the currently selected field when no field is specified.

 

You are correct about what I'm after. I overlooked the fact that Set Field[] uses the currently selected field (when no field is specified). This is so much cleaner. Thank you very much.