How will you determine what field should be copied?
If you can pass the fully qualified field reference as a script parameter, you could use this script:
Set Field [Globals::GlobalCopyField ; GetField ( Get (ScriptParameter ) ) ]
Copy [Globals::GlobalCopyField ]
To pass the field reference as a script parameter, I suggest using:
GetFieldName ( Table::Field )
as this way, any subsequent renaming of either the table or the field will not "break" your script as it will update the text passed in the script parameter to use the new name(s) automatically.
I am figuring that the script trigger would be 'OnObjectEntry' for each of the fields in question; then it would be easy to grab whatever the 'source' field is going to be.
Yeah, that is pretty much the script that I had in mind, assuming that global field was used as the target for populate-then-copy. That's a good suggestion to use of GFN(); we already have that CF in our solution to use with ESQL statements. :)
OnObjectEntry could use Get ( ActiveFieldTablename) and Get ( ActiveFieldName ) to access the needed info to pass as a script parameter.
GetFieldName, BTW, is not a custom function (CF).
Hmm, but if a user clicks into an edit box, modifies the data and then pastes from the clipboard, the pasted data will be the data present in the field before the user modified it if you use OnObjectEnter. Might want to use OnObjectExit for this instead of onObjectEnter.
An additional aspect of my script is to prevent the user from making changes:
exit script (0)
So, I hopefully don't have to worry about them changing the data. This layout isn't intended for editing, anyway, just to copy to the clipboard.
Ah, I see it now: GetFieldName(). One of the Logic functions (seems like a curious category). We have a CF "GFN()" that we use for our SQL statements that just returns just the field part, not the fully qualified name. But the fully qualified one is better in this case.
It may be safer to use calculation fields that simply copy the data from a specified data field to prevent possible changes.
Try using drag and drop to drag data onto one of the fields in your layout. I suspect that it is still possible to use that method to modify data in your fields.
Grrr...worked through most of my bugs but have been running into one last one, and it is the very last script step. :)
My sequence goes thusly:
* I have an instance of a field from Table Z on a layout; this field has a script trigger to script A.
* Script A just calls two other scripts, B (with parameter) and C.
* Script B collects a list of values using an ESQL statement, and based on the script parameter. It then sets a global field in Table Dev_Globals.
* Script C has only two steps (as output by a 'print to PDF' of the script):
Copy [ Dev_Globals::Field_For_Copy_Script_g ] [ Select ]
(that field in the Copy statement is the global field set by Script B)
But for some reason my clipboard comes up empty. When I look at the global field in Data Viewer, it has the correct list of values. All of my script steps before that show the correct list of values at various places. But my Copy() statement doesn't work.
I know trying to troubleshoot stuff in this manner is a pain in the kneck, but does anyone have any ideas? Is there some esoteric restriction on copying from a global field?
Doh! Amazing what a bit of sleep can do.
I think the root of my problem above was the fact that I didn't have the field that I was copying on the layout itself. However, that was complicated by the fact that I had a bug in one of my scripts where I was defining the wrong field (i.e. not the field I was ultimately trying to copy).
With those two things figured out, it works fine now.
Yep, copy, paste and the script steps that start with the word "insert" all fail silently unless the field is both present on the layout and enabled for browse mode access. If you don't want the field to be noticeable, you can make it just a few pixels in size and hide it behind a button, tab control or other opaque object. On the very rare occasions that I hide a field like this, I put some layout text on the layout noting this fact and use conditional formatting to make the layout text invisible when in browse mode.
I haven't tried this, but I wonder if those steps will work if the field is positioned to the right of FMP 12's new layout boundary?
Yep, they will. That is what I did. :)
A lot of what we want to do with the clipboard could be simplified with the following features: