I think this will work. If you had FMP 10, you could use a script trigger.
The way I read your post is that you aren't actually "hiding" a field, you want to "lock" the field in specific records so that the user can't modify your "yes/no" field.
With that assumption, you need some way to desginate specific records as "locked". You can add a text field to your portal's table and use a different layout (that the user can't see) to put "locked" in this field for any record that you don't want the user to modify the yes/no field.
Now write a script:
If [Portaltablename::Lockfield = "Locked"]
Set Field [Portaltablename::YesNo; "Yes" /* return field to original "yes" value */
Now go to your layout, enter layout mode, select the yes/no field and Format/button setup... to select the above script to run when the user clicks the yes/no field.
If the above method keeps you from selecting both yes or no for the unlocked fields, you'll need to create two invisible buttons and place one over the "yes" radio button and one over the "no" radio button. Then you can use scripting to respond to the user's input and put "yes" or "No" into the field.
PilModJunk: This is a great response, unfortunately as of now (with the budget being what it is) my office is not planning to upgrade to FMP10 for a little while. So, I really need to find a way to do this in v.9.
Thanks though - you've given me some thoughts I didn't have before. Maybe invisible buttons could be used in some way (?).
Any other thoughts?
Read my post again. I gave you two options:
1) get fmp 10
2) follow the steps given in the post. They should work for pre-10 versions-You'll even find I meantioned your "invisible buttons" :smileywink:
Thanks - yes, I knew that you gave me the invisible button idea! I was just clumsy giving you credit for it, but that's what I meant.
I see now, though, that this method should work for FMP9; however, in my DB it does not work. This particular database is going to be accessed exclusively via web browsers. I'm finding that if I have a portal with 20 records in it, but it only shows 10 at a time and the user scrolls down to the 20th record and clicks the button that triggers the script you described, then for some reason the interface flips back up to portalRow #1. I can't keep this from happening (I've tried Go To Portal Row approaches, and they do not work).
So - I need to use strict radio buttons or checkboxes (I think) since running a script inside the portal seems to flip the user up to the top of the portal, forcing them to scroll back down and find their place again.
Thanks for your help -- and if I'm missing something, please let me know! I'm going crazy trying to get relatively simple things to work in a web environment.
I don't have 9 (I use 10) and I don't have any experience with publishing FMP to the web. That severly limits the help I can give. You might want to start a new thread asking about "portal pop" in a web browser and see what advice you get.
That said, there's one more thing...
In my version, using just FMP 10adv, I have a portal option "Reset scroll bar when exiting a record." I have no idea if this setting is available to you or if it will affect the portal's behavior in a browser window, but if this option is selected for your portal, maybe "unchecking" it'll solve your problem.
I do have that setting, but it doesn't seem to help. Thanks for your help. I have found an ineligent solution, for your information:
I created a new instance of the portal table that is related to the first instance of the portal table. The relationship states that the ID of the record has to match AND a value in a "Locked" field has to NOT match.
Then on my layout I have the text coming from the first Portal table and the Y/N field coming from the second instance of the Portal table.
This works to make it impossible for the user to select Y or N in the portal for locked items. The downside is that they can still see the Y and the N radio buttons there -- they just can't select them.
So - that's probably good enough for now, but I will take your advice about creating a post related to the "popping" behavior of the portals online.