You could use conditional formatting to hide objects, but users can click into them if they know where they are, or you can use portals, an old example is here http://www.databasepros.com/FMPro?-DB=resources.fp5&-lay=cgi&-format=list.html&-FIND=+&resource_id=DBPros000743
or you can use Tabs, depending on which version of FileMaker you are using, and hide the object on a named tab and call that Named object in your script using the Go To Object script step, not sure where there are any examples on the web but if you want to go down this route I could walk you through it.
Hello Orlando. Thanks for the response.
I have downloaded the link and run Visibility v7 db. I can see the hidden fields being shown but what is triggering this? There are no script triggers that I can see. Are the fields just dummy (empty) fields in the db? I am used to event driven programming and find this somewhat confusing.
The Visible7 demo does not use any script triggering or anything, it uses calculations that check if the field is empty or not, and if not inputs the records ID.
That calculation in-turn is used in a Self Join Relationship, one for each object, by the Visibility [Field] calculation and the records Serial [Unique ID]
The layout then has a portal based on the appropriate relationship for that object, and only displaying one row of the portal. the portal is tightly wrapped around the field and the label, so can be hard to spot.
So when you input a value into the first field, the calculation gets populated with the records unique ID and the relationship gets activated, displaying the related record, which is itself in the single row portal. Therefor displaying the next field.
I hope this explains it well enough, there is also an info layout that may explain in more detail.
Let me know if you want help setting this in your system.
which version of FileMaker are you using by the way?
I think I need to take a closer look at portals. I am evaluating FileMaker V10 for possible use to replace a legacy VB6/Access application. I am finding the lack of control over the db front end pretty frustrating. I am still of the opinion that this is just the learning curve and I need to stick at it.
I have copied across the Customer table (and supporting foreign tables) from Access and I am trying to mimic the functionality of the VB/Access application. In this application there are 3 modes 'View', 'Edit' and 'New'. The front end is almost never connected to the db. I use Update, Insert or Select SQL to manipulate the db data (and structure) and show the data on screen. I can address a text box on screen, which although shows data from the db is not connected to it. This is very useful. Being able to create and address recordsets is very useful too.
It works well but it is Microsoft and it is VB6 and that is a worry. It is legacy. I wanted the replacement to be more platform independent and to be more closely connected to the data. I have looked at MySQL (which seems devoid of any front end), SQL server, which seems to be a huge complex beast, Oracle lite similarly and Access 2008, which is still not really suited to multi user environments.
My last option if I am unsuccessful with FileMaker is to rewrite in .Net (VB7 really) and use SQL server as the db. I am due to refresh my .Net skills on a course next month. The problem with this type of programming is the lack of control and lack of standardisation. Although I am finding FileMaker restrictive, these restrictions force some control over the end application, which is a positive. I can't help feel though that there has been a lot of effort put into changing the db structure in order to manipulate the user interface.
I suppose it is all down to control versus flexibility at the end of the day. Good control = low flexibility, No control = total flexibility.