Script steps that start with the word "Insert"
All require that the field be present on the current layout or they don't work.
All put the focus in the specified field--which can trip a number of script triggers and not just on the specified field.
These "brittle" characteristics mean that, when possible, you should not use them but use alternative steps that do not have these characteristics. (I use the term "brittle", because simple small design changes can break them.)
In addition, copy replaces any data that the user may have previously copied with the data copied by this script step. That can confuse and irritate your users.
But sometimes these steps are still the right ones to use--you then have to take steps to minimize the consequences of these brittle characteristics.
+1 on Phils post. Sometimes you have got to Copy - but you really should consider other options (Set Field, Set Variable...). You could consider a "Utility" layout where you place fields you need to Copy/Paste/Clear/Insert, write a notice on that layout that specifies "Do Not Remove Fields From This Layout", and then spawn a new window to that layout when you need to use brute force. (Don't forget to close the new window after operations)
"I can stand brute force, but brute reason is quite unbearable. There is something unfair about its use. It is hitting below the intellect." ~Oscar Wilde
plus Phil and Stephen!
create a pop-over with the field (as named object) and
Go to Object
then copy. That assures the field is there, but is not shown until you need it.
Or use a "hide object when" that has a value ($$variable) that can be changed by script, such that is not hidden to allow copy and clear the $$variable after copy.
but heed the warnings of stepping on the clipboard.
You can also place the field off the right hand edge of the layout. If you do, put very visible layout text next to it telling your future self and any fellow developers why that field is there.
But a utility layout is best as this ensures that you aren't also tripping script triggers--not only those that might be currently on your layout, but those someone--even you, might add to the layout in the future.
To hide the field, you can put it outside of right border of layout.
Add: wow, just already mentioned by phil.
I think Phil hit the nail on the head... The field is not on the current layout and I had to add it to the table because the actual field I want to copy to the clipboard has a on-object enter trigger and the copy causes the trigger to fire again which is not the behavior I need. So this other field was just a work around for the trigger/Copy issue.
Many thanks to you all, especially Phil, who's explanation make total sense to me!
Granted that you have the answer to the question you asked, but your script snippet leads me to ask a question of you:
In line 27 you set a field with the value of a variable $currentPW. In line 28 you copy that same value to the clipboard. Since, at that point the variable still exists I can't help but wonder why you are doing this? Is this script serving just that purpose—to post the current password to the clipboard? If you want it to be available on the clipboard for external uses then I guess you've achieved that, but with all the pitfalls of the clipboard. But if you are going on inside FM to use this value in some way, then use the variable you already have instead.
I found the same question floating in my mind, keywords. It would help if OP would say why the contents needs to be ON the clipboard.
As I said above, I cannot use the original field because it has an on-object-enter trigger for some other logic I need, The "copy" script step does fire the trigger which is not the behavior I need. That is why I created the 2nd field with the same data but without a trigger. But as Phil points out, the field needs to be on the current layout for the copy to work. I did not know this was a requirement for the Copy step as this is not mentioned in the documentation I was looking at for this script step.
You have explained why you needed to add a field to your layout.
You have not explained why you want to copy data to the clipboard.
Copying data to the clipboard is rarely necessary.
Oh..sorry. It is because I need some of my users to be able to use the data in this field in other applications within the OS (the field is defined as "Concealed edit box" in the layout). The only way I know how to do that is via the clipboard and I made it easy of rte user by using a button that executes the copy script.
Yes that is the typical use for copying to the clipboard--to make the data "paste-able" into other applications.
But you didn't need to add another field just so that you can copy the data.
Option 1. Set up a Utility layout with the fields that you need for copying but no script triggers. Have your script go to this layout, copy the data, and return.
Option 2. Use a global variable to disable script triggers. Start every script that is performed by a script trigger with this code:
If [$$TriggersOff ]
Put rest of script here
Then any script that might trip a script trigger where you don't want this trigger tripped:
Set Variable [$$TriggersOff ; Value: True ]
And then you need to set the variable to "" or False before this script exits so that you don't leave triggers disabled after running the script.
Got it! Thanks again!!!