New Visibility with vs. 11

[LaRetta]

With vs. 11, we can now easily display certain fields only when others meet our criteria. It requires no additional calculations and one simple self-join for all of the fields we wish to show or hide.

Create a new record and type into the text field. Simply use one-row portal (with your criteria on the portal filter) as attached.

UPDATE: As with any visibility technique, you may wish to apply rules if text2's data is removed and there is still a value in text3. There are many things you can do with script triggers and/or auto-enter (replace) to remove the value from text3, stop text2 from being cleared and so on ...

visible11.zip

Edited May 2, 2010 by Guest
Simplified conditional format

[Noobee]

Can this work with container fields as well?

[Søren Dyhr]

As with the old visibility as well, should attention be paid to what kind of metaphors the user usually expect to roam in. Under Windows and Linux, isn't the discurse so narrowly defined as:

http://developer.apple.com/mac/library/documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGHIDesign/XHIGHIDesign.html#//apple_ref/doc/uid/TP30000353-TP6

...and pulling white rabbits out of a magicians hat, doesn't quite abide, metaphorically speaking! Urges to bloat a solution with gizmos and other gadget'ering - ought consulting this:

http://www.smallco.net/RestrainYourself.pdf

--sd

[LaRetta]

Hi Søren!!

I see no rabbits or hats here at all. Visibility (only displaying fields when applicable) is standard in the software industry (including Apple Interface Guidelines).

Take PayPal ... if someone is paying by bank, it then displays bank information fields and does not display credit card fields and vice versa. If a health exam asks for gender and if male, it doesn't bother displaying a question such as "when was last mammogram."

Now with vs. 11 and the ease of implementation, there is no reason NOT to take advantage of this ability.

[LaRetta]

Hi Noobee,

Any fields (including several fields) can be included in the filtered portal. For instance, if question is Gender then you can display all fields which relate to that specific gender for easy answering, since a single portal row can be any size and include many fields.

The one-row filtered portal can also be used instead of calculations in some instances. For instance, a User wants an Excel file and they want to know the customer who purchased the highest quantity of Gizmos in one order but only for Product = "Gizmo". You can filter the related lineitems table portal to Product = "Gizmo" and sort descending on quantity. Place the related fields you wish to export within the portal.

When you Save As Excel, you cannot use table view (tables do not recognize portals and, if related fields are placed in table, the first related according to the relationship sort will always display). But use a List view (or Form view) and then that one-row portal with the related values will appear in the Excel worksheet.

So filtered portals can, in many cases, replace calculation fields and 'auxiliary' relationships. You can also grab these values into variable simply by going to the filtered portal first (and even GTRR to this found set if going to portal first). I am finding that I don't always need a calculation or filtered relationship if I have a developer layout with filtered portals to grab filtered values.

I think filtered portals are the greatest thing since List(). :laugh2:

[Søren Dyhr]

What I really wished to say here was, if something disappears irretrievable - would it violate the "forgiveness" clause.

So the rabbit as chosen slightly misleading.

--sd

[bruceR]

You can also grab these values into variable simply by going to the filtered portal first (and even GTRR to this found set if going to portal first).

As in the example file I provided on sorted portals, if you name the portal field(s) you do not need to go to them. You can get them with getLayoutObjectAttribute( "yourFieldObjectName"; "content"; 1; portalRow )

[LaRetta]

Ah, I had forgotten about that. Thanks for the reminder!

[LaRetta]

I don't see visibility any differently than anything else. We must plan contingency. As I mentioned, it would be business rule that, if data is removed from field 2, would auto-enter (replace) remove it from field 3? Or would script trigger disallow removal from field 2 if field 3 had data; or disallow entry back into field 2 so data couldn't be deleted?

It would be same rules as if the fields were being modified locally. Just because field 3's portal might make it appear that the data has disappeared, it is still in the same record as the parent (in this instance). I believe that, regardless where the data resides, a developer can plan for contingency and handle it quite easily.

But I am glad you brought it up so others can see that these issues must be considered when designing anything.

[john9210]

Pretty neat! Thanks for the demo file. One thing: to get text3 field to appear you have to click outside a field. You can't use tab either. I attached a script trigger to commit the record when you tab out of the field. Then field3 appears beautifully. You might consider updating the Visible11 file to do this.

[TrulySimple]

Laretta,

I do not get how it is working? I tested and created a field text4 to see will it still work, and no this is regular. I option dragged from text3 to keep the same conditional formatting.

I see no scrip triggers, I created a portal with flds text1,2,3,and 4 to see what happens as the fields disappear that contain data and the data remains when the field is not visible.

What am I missing here? Trying to catch up from a long gap from working in FileMaker. )

[Steve E.]

The exalted advanced Filemakians did not make this as obvious for us acolytes as they might have. Slick is their ritual here.

Make a portal and click "Filter portal records." Then enter whatever conditions you like for visibility to magically appear. But do heed concerns for data retention when invisibility again shrouds the data!

[TrulySimple]

Long time since I am back. Thanks Steve E. Yes it does work. I was unable before to locate the portal that was surrounding the fields. Now I just would like to be able to use this technique in an existing portal row.

Since there are no portals within portals I may just have to settle for script trigger control on the specific fields that I would prefer to be hidden unless certain criteria are met.

Any ideas?

[LaRetta]

Oh, I appear to be a bit late in responding to your question ... like 2 years late? My deepest apology.  I must have been swamped at the time and it just got away from me. 

 

If you still have a problem with it then well, ahm, let us know.