You can place the field in a portal and set up the portal's relationship so that Yes in the answer field defines a valid relationship to the Portals Table Occurrence. You can hide the portal borders by making them 0 width or transparent.
Thank you for the input. I was hoping there was an easier way to do it. What I have done is/was I created a new conditional value list with yes and the answers, then no with no answers. It seems to be working except the box starts out transparent but after a selection is made either yes or no, it shows up but you can only select answer answers if it is yes.
As to your response, when the select yes how is it related to the portal? Like I have done above, through a script , database table relationship or by conditional formatting. When I place the portal it asks me to select what data to show, I don't see anything to show a relationship between the 2 fields. I am not sure how to set the relationship between the fields. Thank you for your help in advance.
this can even be done by a check box if that can help. This might even be better.
You include your check box field as a key in your relationship to the Table Occurrence on which your portal is based.
Let's say you have a typical relationship for your portal
MainTable:: PrimaryKey = PortalTO::ForeignKey
What you do, is add another pair of field.
In the table of the PortalTO, define a calculation field set to return text and enter "Yes" (include the quotes). Call it cYesKey
Now modify your relationship:
MainTable:: PrimaryKey = PortalTO::ForeignKey AND
MainTable::CheckBoxField = PortalTO::cYesKey
When CheckBoxField is blank or has any value other than "Yes", nothing will appear in the portal. Click "Yes" and it appears.
Another way to accomplish this which may or may not fit the app is to place a clear button over the "Yes" answer which triggers the following script:
Setfield [Yourfield ; "Yes"]
GotoField [Dropdownlist] ###optional
The "Dropdown" layout has the dropdown menu and another clear button over "no" to send you back to the non-dropdown layout if the user changes their mind.
This approach assumes a survey-like screen and would multiply layouts quickly, becoming overbearing, if this is a series of questions/options. If it's only one or two...give this approach a think.
Using Ninja's approach you could even make the field the button and eliminate the need for a transparent button on top of it--which makes for easier layout maintenance.
The trade off here is now you have two layouts to update instead of one each time you have to make changes.
Be careful of making the field the button when it's a Yes/No.
With the field itself as a button, you have only one button...yet you need to differentiate between "Yes" and "No" (thus the transparent 'half-button' over only the "Yes" part).
If they click "No", you want the field to just take the data and do nothing else.
Vice versa on the dropdown layout (if used).
Since you have just two values (yes, no or yes, <empty>), your script can check the value of the field before changing it and "toggle" the value.
"toggle" the value.
A good point indeed, but with a hitch...
I personally would find it disconcerting to see a field that is marked "Yes", and click on "Yes" and have the field change to "No".
At that point, however, it is a matter of comfort rather than function. The toggle idea will work as presented by Phil...it would simply be against my personal grain. And my 'grain' isn't part of the topic.
I'm picturing a check box with a single value. As such the "scripted" behavior will exactly match the behavior you'd expect for checking or unchecking a single value check box field.
Makes sense to me. I was picturing a survey or service request:
Do you want your car washed as part of this service? o Yes o No with a dropdown for types of wash...
Do you want automatic email newsletters? To home, work, mobile, ...
Do you use fabric softener? Brands, stores, price range, bottle sizes...
All things where a positive answer is desired rather than an answer by omission.
Both of our ways will work fine, the real app circumstances would define the best one to use.
Thank you for all the options. I will try all of them and will let you know which is the best for my needs. I am creating a database for a job finding agency in Italy. The specific box in question is a box that asks if the person is disabled and if so by which category. I have about 5 of these to do so I am trying to find the safest way to cause less errors on my part and less user errors. I am new to Filemaker and I have even bought the video by lynda.com and there is nothing there about this. Thank you so much for the options you all have given me.