In order to do this, you need to have the "yes" image stored in a global field somewhere that is accessible to the calculation. That means, it needs to be in a global field, or one that can be visible via a relationship to the record(s) in question. A 'Cartesian' relationship (the 'x' option in the Edit Relationship dialog) will often do the trick here.
Once you have the stored image, you would have a calculation something like this:
If ( radioButtonField = "Yes" ; relationship::imageStoreYes ; relationship::imageStoreNo )
and make sure you select the Calculation result type in the drop-down menu at the bottom of the Specify Calculation dialog.
... and obviously this extends to a Case statement if required:
Case ( radioButtonField = "Yes" ;
radioButtonField = "Maybe" ;
Thanks for the guidence, job sorted
Further to Rob's solution, if you have more than one image to store (yes, no, pending, in progress, etc) you can store all images in a repeating global field and use GetRepetition to apply the required button image.
I have created a layout in my database to store all the global images of the parts that I want to use for the calculation. Whenever I try to save the image to the container fields, when I exit out of the database, it won't save the image. I can't figure out why the images will not save in the container fields.
Sounds your seting up your glaobals in a Multi record Table, won't work.
What is needed is a single record Table Global [GBL], that has Stored Container and mirrored Global Container fields of sufficient Repetitions, i,e.;
Flag w/ say 6 Repetitions that has the stored image and
Flag_g w/ again 6 Repetitions this is the global that gets populated at Startup.
Set Field [ Flag_g ; Flag ] ;
Set Field [ Flag_g ; Flag  ] ; etc.
Then in table that is referncing the Flag_g there is the Toggle Flag is "Yes" or "No" field, then the display containers is:
FieldName = GLB::Flag_g [ Case ( Flag = "Yes" ; 1 ; Flag = "No" ; 2 ; 3 ) ] Note: 3 is an EMPTY global repetition.
I think you have encountered a standard glitch when using a FileMaker Server hosted database and global fields. When a file is moved from the desktop machine to the server, the values in global fields are captured with their current contents and all users who access the file get the values as they last were on the desktop, UNLESS you do something to set them up.
There are two way to do this, and frequently people use both.
1) Set up non-global equivalent fields in a single record table. Then, in the startup script for the file, use Set Field() steps to populate the global fields with the correct values. This works for containers the same way it does for all other field types.
2) Set the values in the local file before moving it to server. Sometimes this is best achieved by using a closing script that sets (or clears out) global field values in the way you want. That way, even if you take the file off server for some reason, open it to make changes, then close it, you will have prepared it to go back on server with the correct values.
You can do both scripts on the file now, even if it is on server. The closing script values won't 'stick' until you take the file down, open then close the file with FMPro (locally) and put it back on server, but you'll be ready to do that anytime it is convenient.
-- Drew Tenenholz
Yes, I am using Filemaker server so I think you are spot on. I will have to check into it, and see if I can set up it up the way you decsribed. I am new to the all the server stuff.
what would happen if I moved the images to the server? Would that help any?
No, that won't help.
You can pull the file down, run it locally and populate the globals then put it back up.
Create a server side script which populates the globals.
Malcolm is right here. I'd like to point out that although this is a bit confusing for someone new to FileMaker, there is a really good reason for why it works this way.
Succinctly put, global fields have the same values in all records AND ARE UNIQUE TO THE SPECIFIC USER/SESSION.
This is a really good thing, but it might take a minute to get your head around the issue. In your case, you actually of want FileMaker to do two things at once. When one field has a particular value, you want a graphic to appear the same no matter what record that user is on. But you also want two different users to have the opportunity to see a different graphic from each other, should the field value be different for those two users.
FileMaker engineers already took care of this by making the global fields be capable of holding different values for different users. But, since they are different, you need to pre-set the value for each and every user. Thus, a startup script.
Hope that makes this clearer.