Thank you for your post.
Yes, I can duplicate the problem, and I have forwarded your entire post (along with my findings running Mac OS X 10.5.7) to our Development and Software Quality Assurance (Testing) departments for review and confirmation. When I receive more information back from those departments, I will let you know.
Thank you so much, I appreciate it.
Looking forward to a fix.
Depending on what you are pasting, you may be able to avoid this issue by using the set field and set variable steps.
Unfortunately, no (unless I'm missing something).
I provided a button for the user specifically to paste into the field the clipboard's content.
But thanks for the suggestion.
Hmmm, it's a bit clumsy but
Go to layout [different layout from what's visible but which contains table::globalfield]
Paste [select, table::globalfield]
Set field [table::FieldYouWantToRecieveThePaste; table::globalfield]
Go to layout [original layout]
Would work around the bug until it's fixed.
Yep, that would work. Actually, I created a separate hidden field on the same layout.
I've been called in to solve another developer's problems with a script and traced the script's unexpected behavior to a layout edit that removed a field that was the target of a copy or paste script step.
As a result, whenever I've had to use copy or paste, I've set up "scratch" layouts that I keep hidden from the user and switch to these layouts for the copy or paste step. I then add layout text to this layout stating:
"These fields are needed in order for script(s): <list script names>. Deleting a field from here will break at least one of these scripts."
That seems a bit "safer".