I would ask yourself why you want to do this? What are you trying to accomplish?
Table::field for the current record always has the value.
If you create an on object enter script trigger that uses Set Variable ( $$v = Get (ActiveFieldContents ) ) then the global variable $$v will contain the value in Table::field
As i said i think their is more to this story
The database I am working with has microscopic images that need to be classified by multiple criteria, e.g., size, shape, etc. Each image is classified by multiple users for each of the criteria. Then a final classification is made by another user. That user sees a matrix of fields, e.g., User1::Shape, User2::Shape, User3::Shape and needs to decide which to select as the final Shape classification for the image. I know that I could set up a script trigger that would give the active contents of the field selected but I would rather have that field set up as a button that would get the selected field contents and then populate another table that contains the final classifications. Thus, for example, by clicking on User2::Shape (which is a button) the field "Shape" in the final classifications table will be populated with the contents of User2::Shape.
I've run into this myself. The only solution I've found is, as coherentkris says, to use an onObjectEnter trigger rather than a button. Buttons don't become "active" when clicked, so you can't use any of the "Get (Current..." functions to get information about the field contained in the button, or even the object name, etc. for the button itself, without entering any of the information you want in the script parameter (and ensuring it's in synch if any changes get made to the underlying object, field, etc.).
I sure wish we could, though.
You already received an answer in your initial question (from your status update) – what's wrong with that?
On the other hand, I would re-consider the data model:
Image --< ClassificationType (shape, size etc.) --< ClassificationTypeByUser >-- User
Now the “final user” can browse through an image's ClassificationType records, see the related ClassificationTypeByUser records and select (via script) one of them to set its value (or maybe better its ID) into the ClassificationType record.
No need for any triggers; just an ordinary script that you attach to a field in the ClassificationTypeByUser portal.
Thanks for your original suggestion. Unless I misunderstand what you are suggesting (which is certainly possible) it seems to me that this is still using a script trigger and not a button. I think the setup I have is basically what you are suggesting. The user making the final decision is viewing the image and below the image is a portal with the Users 1, 2 and 3 as rows and the various classifications (Shape, size, etc.) as columns. I don't understand what you mean by "No need for any triggers; just an ordinary script that you attach to a field in the ClassificationTypeByUser portal.". Isn't that in fact setting up a button to run the script?
Thanks for your original suggestion. Unless I misunderstand what you are suggesting (which is certainly possible) it seems to me that this is still using a script trigger and not a button
Actually, why would you care what it is, as long as it does the job?
As has been pointed out, a script using a button cannot be abstracted in the same way that a field trigger can, because if the field is a button you cannot use any functions that are based on the field's identity [namely, Get ( ActiveFieldxxx )].
I think the setup I have is basically what you are suggesting.
But only basically, because you're missing one table; and that is the root of all evil cause for your issue.
In your setup, each of the portal records the superuser sees, and where you want to apply your script, knows unambiguously …
• the image
• the user
The problem here is that the table is non-normalized, because you then you have several fields, each pertaining to a different classification (you could label them classification1, classification2, which would make the problem clearer) …
and that is why you see the need to have an abstracted script that can not only read a field's value, but also which field it is.
(What I don't understand is why you want to store these values in a variable, rather than writing them directly into their target field …?)
In a fully normalized setup, like described before:
Image --< Classification --< ClassificationByUser >-- User
, each record in ClassificationByUser knows …
• the image
• the classification“Type”
• the user
• the user-entered value
You would first select the image, then the attribute (ClassificationType), and only then see the user classifications (in a portal of ClassificationTypeByUser); at that point, you can use a script that is simply
Set Field [ ClassificationType::finalRating ; ClassificationTypeByUser::rating ]
because these records all belong to one classification – the selected ClassificationType.
But the world is a messy place, and implementing a correctly normalized structure would (probably) require too much effort … <sigh>
I understand your point about normalization but this database is over ten years old and I am not authorized to spend too much time on restructuring it. I agree that the world is a messy place.
Thanks for your input and suggestions, though.
I have a matrix of fields, each containing data. I would like to convert the fields into buttons, running a single script (based on the script parameter) that can create a variable that will contain the contents of the selected button (field). I can do this using a script trigger but when clicking on the button (which is the field), it is no longer recognized as the active field. I would very much appreciate any suggestions as to how to accomplish this.
As you know, converting a field into a button means you can't make it "active" ( ie. make its content selectable).
A method I have used is GetLayoutObjectAttribute. With a field, the attribute you want is its "content".
Therefore if I have grid of fields, I first give each field an object number say from 1 through to 20. I then convert each field into a button calling one script and each button has a parameter which also goes from 1 to 20. That is, the parameter equals the Object's name. Here's a sample script: (Note I show the use of a variable because you wanted it, although you could simply set a destination field directly)
Get the field's value based on the button's script parameter and Object name...
Set Variable [ $var; Value:GetLayoutObjectAttribute ( Get(ScriptParameter) ; "content" ) ]
Set a destination field to the variable...
Set Field [ Destination; $var ]
Attached is demo file:
FieldsAsButtons.fp7.zip 133.9 K
Thanks, Ralph! That worked.