a script to go to correct layout containing certain field

[tmanning]

Hi! I am not sure where to post this but this looks like a good category...

I have a file that is a "questionaire" type of file. I have about 100 fields but each field is on a different layout. At the end when I am error checking, if a field has been found to be left blank or filled out in error, how can I get the script to take the user back to the layout that has the correct field on it? I don't want to write a lengthy script that check each and every layout by name. I have noticed that FileMaker won't let you use variables for fields, layouts, and scripts. Each time I want to write a similar script for a layout, I have to hard code 100 + scripts. I know there must be a better way to do this.

Thanks,

Tracy [email protected]

[Thom]

The Go to Layout step has an option, "layout number from field". You can set a field to the appropriate layout number, then call this step.

[danjacoby]

Check the "Validation" in Define Fields -- you can make sure that the person doesn't leave the field blank, and that the field contains certain information. That way, when the user tries to leave the layout, he or she will get an error message and have to fix the problem before moving on. Then you don't have to check up on anyone.

HTH,

Dan

[tmanning]

I know I can go to a layout number but how does the script dynamically know which layout number to go to? I don't if the field that is blank is on layout #5, how does the script know to get back to layout number 5?

Also, the define fields: validation doesn't work. Since the user is not creating a new record (there is only one record in the database) I cannot use the option to validate that a certain field is not empty. This works especially bad when the user is on a different layout when the program catches the empty field because it continues to alert the user about the empty field and won't let them do anything until the field is filled in, which they cannot do becuase that field isn't on the present layout. This leads me back to the original problem - how can I get Filemaker to know what fields are on which layouts?

[ December 26, 2001: Message edited by: tmanning ]

[SteveB]

You need to use a script to navigate to a layout. Use a global field(numeric)to save the layout number by using

field= Status(CurrentLayoutNumber)

before you transfer to the layout.

Then you can use GoTo Layout(layout from field)

[tmanning]

I am sorry but that does not help me. Imagine this... You have 100 questions on 100 layouts. At the end, the user clicks a button called "check for errors" and the program goes to a hidden layout with all the fields present and checks each field to see if it has the correct data in it. If the field is empty or has incorrect data, the script will stop, give an error message and take the user to the layout with the field on it so they can fill in the missing information. Question: How does the script know which layout that field is on so it knows where to go to? I am trying not to hard code things since the questionaire is likely to change from time to time.

Again, since this database has only one record, basic field validation is of very little use to me since it only checks for empty fields when a new record is created.

Thank you for consideration to this question.

Tracy Manning

[Thom]

Instead of checking one layout with all the fields on it, check each field on its own layout. If there is an error, just stop; you will be on the correct layout.

You could make a "Please Wait" layout to display while the fields are being checked. Your script would go to this layout, refresh the screen, go to the original layout, and continue moving through the layouts until either an error is found or the last layout is reached.

If you have to check all the fields on one layout, then there are still several ways to find which layout a field is on. One method requires that the fields be in the same order on consecutive layouts as they are on the AllFields layout. You start by setting a global field to the number of the first layout. Each time a field checks out, you increment the global. If a field has an error, you go to the layout number as stored in the global.

Another way is to store the name of the field you're checking in a global. When you find an error, you loop through the layouts, checking each field for its name.

Instead of 100 field on 100 layouts, you might be better with a few fields, one or two layouts, and 100 records. Each record could hold the question, the answer, and any other relevant info. Instead of switching layouts, you go to the next record. Checking the answers would be easier as well. When you get to a bad answer, you stop on that record. If you need to reset the answer fields, just Replace with a null value.

[Rigsby]

I would do it completely differently. Try this:

Create a file called

[tmanning]

I am afraid that my "questionaire" is very involved and none of those answers will work for me. Each question is on a different layout because 1) there are many different types of questions; some are yes/no, some are short answer, some are long answer and some (such as list every residence you have had since age 18) requires a portal to another file. Also 2) depending on an answer to a certain question, one or more layouts may be skipped. If someone is a US citizen, they do not have to answer questions about visas and residency status, etc. I have thought about making each answer a separate record (making all of the answers global) and having each new question advance both and layout AND a record, but I was afraid that jury-rigging it like that could cause it to be buggy later down the road. Best to stick with one record when you are only dealing with one entity.

I think I have found an answer, though. I am going to get a plug-in that will activate a script upon modifying a field. This is good because I can have a script check for an empty or invalid field while directly on that layout. As for allowing the person to skip questions and come back to them as necessary (such as gathering addresses for credit references and more involved questions) I will have to deal with that as a separate issue.

Thank you all for the input but I guess this is just one of those wierd things that is pretty much going to have to be hard coded from page to page. We all know that hard coding is a bad idea but sometimes, it's just plain unaviodable when you work in a program that isn't good about accepting variables. (By the way, oAzium, the company that makes the plug-in that I am going to purchase, allows you to specify scripts with variables which takes out some of the hard coding. If you guys ever get stuck like I am, consider a plug-in as sometimes they can be helpful.

Thanks again for your help.