It really should be as simple as that. But the field from which you are copying must be physically present on the current layout. If it is not, nothing is copied when you perform the script.
That's one of two reasons why I avoid using copy, paste and insert... scripts except where strictly necessary. The other reason is that copy also destroys any data the user may have previously copied to the clipboard--often an annoying or even confusing result for the user. Any chance that you can get the results that you want by using Set Variable to copy the field's value to a global variable and then using a second script with Set field to put the copied value into the selected target field?
Yes, field is on the current layout (the copied field); it's in a portal row, if that matters. I don't have it setting a field definition anywhere, yet. The user just asked to be able to copy the contents, so I don't think they will mind if this overwrites their clipboard. I am not sure that it is even intended to be used inside the solution, so don't know if it needs a paste anywhere; will have to check.
It appears that the copy will work if 'Field Entry:Browse Mode' is enabled. But now need to figure out how to prevent the user from changing the field. Seems like I have seen a script trigger work for this somewhere...
Make sure that the copy button is also in the portal row or it won't necessarily copy from the correct record. I use copy so seldom that I hadn't noticed that fields that deny access in browse mode cannot be copied by this script step but a quick test on my part also would not copy from a field so locked against user access.
Your script could freeze the window, use Go To Related Records to go to the portal's record on a layout based on the portal table, copy from the field there (Where access can be permitted) and then return to the original layout.
Or you can put a calculation field in your portal in place of the original data field. The field's calculation expression would be simply the name of the original field. This field will allow entry into the field (where users can copy and/or drag from) without any special scripting, yet the user will be unable to modify the contents of the field on that layout.
Why not an OnObjctEnter trigger that fires:
Copy [ Select ]
allowing entry into the field ?
Phil, yes the button is in the row. It is the row's data field itself that I made into a button.
Ray's idea seems to work pretty well. Thanks Ray. I have left the button settings to be the copy portion, though, and just put the Commit in the script trigger script.
I have a text field that is locked for change. I want to copy the contents of the field to the clipboard when the field is clicked (=the user asks for it). But it shall not be changed by the user. Its an ID number, a change will break relations.
Can I be sure the user won't be able to change the contents of the field if I make the field a button and run the above script?
Mine is working that way: The user clicks the field, the contents of it get copied, and then they are bounced out of the field by the commit. Turn off User Abort and this should be pretty safe. I haven't tried real hard to try and break it, however. :)
Another method would be to add a parameter to the script trigger (OnObjectEnter or even OnObjectModify): Get(ActiveFieldContents). This should be the contents of the field BEFORE any changes were made to it. You could then either reset the field contents, or check them to see if they are the same.
I have been intrigued by the fact that the Get(ActiveFieldContents) or a reference to the field (i.e. Table::FieldName), attached as a parameter to a script trigger will result in the value of the field BEFORE it has been modified, even if the script trigger fires AFTER an event happens. At least, that is true for OnObjectModify. Then, if you do the same reference INSIDE the script the result will be the MODIFIED value. So even if your first script step if get(activeFieldName) it will be different (if it has changed) from the script parameter version. I haven't checked this with all of the triggers, but certainly with OnObjectModify.