Conditional Visibility of Objects

[bradm98]

Not sure if this is the appropriate forum...

I'm relatively new to FileMaker, but have a fair amount of experience in application and database development. I'm attempting to make certain objects/fields visible based on values in another field (in this case a simple Y/N radio button).

So far, the most 'elegant' solution I've found is to create a self join portal on record_id::c_visible_key, and place the conditionally visible objects within the portal. However, I then had to overlay each radio button option with a transparent button which calls a script to set the field value (One script for Yes, one for No). Otherwise, the portal objects don't become visible/hidden until the user leaves the radio button field.

It seems to work OK, so I suppose I should be happy, but it seems like a sloppy solution for such a small bit of functionality. Is there a better way, or should I just force myself to accept hacks and workarounds as a necessary evil with FileMaker?

[Philland]

I don't see why you couldn't do this with a calc field. A simple "IF(radio button) = "YES", then, "field to display", else, "" the two quote marks indicating to display nothing. Make sure the calc options is marked as unstored to insure it changes as the radio button changes. Also make sure that the calc is set as results = text or results = container etc. to match the field that you will be picking up info from.

Phil

[cjaeger]

a non-hack solution would be to simply switch layouts. that's what they are good for. Instead of a Y/N button you could make a go-to-layout-button

[cjaeger]

Hi Phil

you have to leave the field to make the portal active/inactive, because fields will have to be left to trigger calculations in other fields. Duplicating the layout and go-to button is the intended way of changing visibility in Filemaker.

[bradm98]

Philland -

I need to show/hide more than just field contents - based on the radio button, I want to show/hide a label, a field (which can be edited), and a button.

cjaeger -

I'll play around with multiple layouts - I'm coming from a VB background, so the overhead of 2 layouts with 100+ objects seems a bit much just to hide 3 objects. Maybe it's not an issue in FileMaker..

Additionally, I'm worried about future maintenance - with 2 layouts, I'll need to remember to duplicate any changes on both. Not a problem at this stage, but I like to avoid future run-ins whenever possible.

[Fitch]

I think your self join portal with transparent buttons is the correct evil FileMaker hack.

[Ugo DI LUCA]

Hi,

The visibility trick is a very good choice. In addition, you could use a container calculation field to simulate a radio button....

Eventually, you could use another solution.

Create a repeating container calculation, based upon a global container with same color of backround in first repetition.

Then use unstored calculation

Case(yourcurrentradio= "Yes", GetRepetition (Container, 1), GetRepetition (Container, 0)).

Drop the calc on layout (set it to not allow entry) and place it on the fields you want to hide when the "yes" is checked.

[cjaeger]

Ugo, you are right, but then....

> or should I just force myself to accept hacks and workarounds as a necessary evil with FileMaker?

... we have to answer the question with YES!

[oilman]

Hi,

Hope this helps. I use this to hide and display menu options on a crowded layout. I made three additional field which are not displayed on the layout.

This field are:

MenuStatus Global Text

Constant Calculation 1

Condcalc unstored Calculation Case (IsEmpty (MenuStatus),"",1)

made a self join relationship with Condcalc and constant

Wrote Script

If(Menustatus=1)

Set Field["MenuStatus",""""]

else

Set Field["MenuStatus",""1""]

Endif

also wrote a startup script that call for Menustatus to equal "" so portal and options are hidden when first opening file.

I attached this script to a button and made a portal and installed all the menu option in the portal.

Option appear when the button is press the first time and disappear when press again.

Lionel

[Philland]

I'm not sure I understand why calc fields and scripts are considered hacks and workarounds instead of solutions, but . . .

With the calc fields and container fields you should avoid the need for a portal at all, unless it serves a function other than just visibility.

The "transparent button" over the radio buttons needs only one script not two. A simple if/then or case statement such as IF(radio button) = "YES", SetField (Radio Button), "NO", else, "YES". This will toggle the field.

I use the transparent buttons, calc's and containers like I described and the type Ugo described to change buttons to arrows on "line item" selections and add and subtract pertinent text from estimates.

Phil

[Fitch]

Phil, there are two separate issues here, the radio buttons is one and the visibility is another. In this case it sounds like both are required to accomplish the desired result.

As for why they are "hacks," your point is well taken. I think it's simply that when you get used to doing something a certain way, that starts to seems like the "only" way, or the "best" way, and of course it's frequently true that one program is superior at a given task than another (i.e., it's not just a matter of opinion). In this case, a person who is used to being able to control the visibility of objects is surprised at FileMaker's lacking this feature. So it does. So we hack.

[bradm98]

The toggle script won't quite work because I don't want to set a "default" value for the field. For a new record, the field value is null (""), and a toggle won't quite work properly.

As for hacks, I guess I'm just more used to object oriented programming in which "visible" is a very common property for objects and is usually easy to set through code.

For example, in VB I can attach code to a radio button, which on clicking or modifying would set the visibility property of another object. Hiding or displaying field contents in FileMaker seems to work in a similar way (with a calculated field), as pointed out earlier in this thread. However, to show/hide objects such as buttons or labels or graphics, I needed to create a portal, a calculated key, a self-join relationship, 2 buttons, and 2 scripts. As for using the terms 'hack' or 'workaround,' maybe this is just a semantics issue, or maybe I'm spoiled!

Oh well, I'll just chalk this up to experience...

[Ugo DI LUCA]

Hi,

You won't enter a "default" value into the field but a default key to control the visibility trik. Besides, working with "simulated Menu" sometimes helps.

The single script here is a 2 lines script Toggle for both the Visibility and the Menu/Radio display :

Set Field (Menudisplay, Abs(Menudisplay-1))

Set Field (ControlVisibility, ContolVisibility-1)).

If you really need a "Yes/No" field (text), then use another calculation based on the Menudisplay or attach a script to the previous one.

Check the attachment to see it working.

Hope that helps.

radio.fp5.zip

[bradm98]

Ugo,

The problem with a toggle is that a 2-option radio button without a default value set really has 3 states: Option 1, Option 2, and NULL.

A toggle script will have to define a 'first value' when run on a NULL value field, which may or may not make sense. (In your attachment, Hide? is always set to "Yes" on the first click, even if the user clicks on "No")

Take this example:

Are you hungry? Yes / No

If NULL, display nothing

If Yes, display a menu

If No, display "Have a Nice Day"

In this case, a toggle won't work, even though Yes and No are the only button options.

However, if the default is "I'm Hungry" or "I'm not Hungry" with a single I've changed my mind button, a toggle works great.

I guess it all comes down to design and personal preferences... In my case, though, the toggle doesn't work intuitively for my radio buttons, because I need the NULL value to be distinct and I want the first value to be set based on the user's choice instead of a default value.

[Ugo DI LUCA]

Hi,

I need the NULL value to be distinct and I want the first value to be set based on the user's choice instead of a default value.

I see no problem here...

Instead of one calculated container and a script, use 2 of each (or 3 if you'd like a NULL Value to not be auto-entered)

The Toggle scripts would work in twins.

Script A set ValueA to 1, Value B and C to 0,

Script B set ValueB to 1, Value A and C to 0

Script C set Value C to 1 and Values A and B to 0.

See new attachment where Value C is auto entered and Values A and B are set in twin scripts.

radioNew.fp5.zip

[bradm98]

Exactly. I think we reached the same solution in the end.

Philland's original toggle suggestion was:

The "transparent button" over the radio buttons needs only one script not two. A simple if/then or case statement such as IF(radio button) = "YES", SetField (Radio Button), "NO", else, "YES". This will toggle the field.

However, I needed 2 transparent buttons and 2 scripts to get my desired result. I ended up with a solution almost identical to your visibility relationship method.

Here's an oddity I noticed while toying around with your file:

Under both approaches (container and visibility relationship), the cursor appears to change over a hidden button (if change cursor over button is selected). The container approach, however, appears to allow the button to be clicked 'though the container' whereas the visibility relationship does not allow a button to be triggered. Odd...

[Ugo DI LUCA]

Hi,

That was the purpose of such a comparison.

Well, this is not odd when you understand how it works. A "visibility portal" isn't a Mask...while the container is.

You could mask a portal with a container calculation, but you can't with a "visibility" trick.

Have a look at another attachment which is quite similar here.

Now, you can control the script that the button triggers with an If statement at start step of the script.

If (c_controlContainer = 1)

Exit field

Else

Trigger script.

But you still will be able to "touch" the button..... allow/disallow entry