Maximum Number of Scripts

[HunterBoss]

It just dawned on me how different this forum is to the car forums I used to spend all my time on. I have not yet found one instance of a new poster being chastised for apparently not searching for the answer prior to posting!

At any rate, I think what I need to do to solve my problem is to create a different script for each button I need to create. There might be over 150 buttons. Is that too many scripts? :qwery:

[Ender]

Well President Hunter,

It is helpful if posters first try searching for what they are looking for, but I think we understand that the syntax and relevant key phrases for searching are not always obvious, so we try to supply useful advice or maybe a link to a previous thread about the same topic.

As to your current question, no I don't think there's a maximum number of scripts, but certainly you should always try to reuse scripts when possible. If you have 150 buttons that do a similar operation, then there is likely a way to use a small number of scripts to handle the operation of all or most of them. If you can give examples of what they do, we might have suggestions about methods for reusing the necessary scripts.

[HunterBoss]

Thank you

I appreciate what you said about syntax, etc. Then, not only is syntax a problem, but are you looking in the right forum as well?

I need to move an important and involved company procedure from Word files, Access (sorry for swearing) databases and Excel spreadsheets to FileMaker. It just so happens that at most only 5 employees in my company would need to look at and use this file so I am very interested in the instant web publishing capabilities.

I want to create all the possible fields in this procedure, but have it so that when a field is complete the user is sent to the next appropriate field based on that answer. Sort of a "if yes skip to question 13, else go to the next one." From scouring through too many posts it seems the only way I can do this is to have a button near each field that the user clicks on to continue the navigation process. I was then going to have calculations in the other fields that would fill in "N/A" after the user skipped ahead to question 13. Am I making any sense?

thanks

I like the sound of that, President Hunter, but it's just plain Christopher Tipper

[Ender]

In that case, there are a few different possibilities worth considering, depending on where you want to put the logic.

1. Use one script per button, and have each script have its own logic about how to branch based on the value of the current field.

2. Use one script and have each button pass a branching choice based on a calc right in the script parameter. The script then uses the script parameter to choose where to go next.

Example: If you're on layout 10 (field 10) and the branch for a "yes" answer is to go to layout 13 (field 13) and the branch for a "no" answer is to go to layout 11 (field 11), the script parameter calc could result in the next destination layout, like:

case(field 10="yes"; 13; 11)

and the script could be:

Go to Layout [ by name by calculation: "layout " & get(scriptparameter) ]

The script is pretty simple here, but the parameters within the button definitions could get complex.

3. Use one script, and pass the current field name/number in the script parameter. Then have the script itself do all the branching:

Set Variable [ $fieldNo ; get(scriptparameter) ]

Set Variable [ $value ; getfield("field " & $fieldNo) ]

If [ $fieldNo = 1 ]

If [ $value = "yes" ]

Go to Layout [ Layout 2 ]

Else

Go to Layout [ Layout 3 ]

End If

Else If [ $fieldNo = 2 ]

Set Field [ field 2 ; "NA" ]

Go to Layout [ Layout 3 ]

Else If [ $fieldNo = 3 ]

Go to Layout [ Layout 4 ]

...

End If

This method is a little more verbose, but I think it would be easier to debug and easier to insert additional steps for specific cases.

[HunterBoss]

Thanks

When you say that it's easier to debug do you mean in comparison to option #2 only, or in comparison to both #1 and #2?

I think I'm going to try Option #1 first. As I'm a bit new at this I'm feeling a bit more comfortable with the lots of little steps concept. Even though it may be more time consuming I'll be able to debug each script right away and make sure it's pointing to the right field.

On a completely unrelated note, is the subscription server not working? I signed up for immediate emails to this topic and have not received either of your helpful replies.

[Søren Dyhr]

Set Variable [ $fieldNo ; get(scriptparameter) ]

Set Variable [ $value ; getfield("field " & $fieldNo) ]

Evaluate( might come in handy here:

http://www.fmforums.com/forum/showpost.php?post/187787/

--sd

[Ender]

I was trying to keep things simple, Soren.

Hunter,

3 is easier to debug than 2. 3 is preferable to 1 because you have one place for those steps that might be used by all operations. For example, if you wanted to update the same set of fields with each button, it would be easiest to add and modify those in one place (rather than in 150 scripts.)

[HunterBoss]

Ender

Okay, I think I'm starting to get the hang of this and I completely see how this is going to work -- with one big huge exception.

Just where exactly is the script getting the 3 values from? By 3 values I mean the field we're looking at for an answer, the field that the user is being directed to based on one answer and the 3rd field based on the other answer. Is that part of the get(scriptparameter)?

by the way, I know you're being exceedingly polite and helpful in regards to answering my questions, but do you think this is a reasonable road to go down?

also, I will try to study up on evaluate a bit more. I saw that in some other posts but wasn't sure how to apply it to this situation.

thanks

Christopher

[Ender]

In my example, the fields are named with a consistent format, "field 1", "field 2", etc. They should probably have better names like "Question 1", "Question 2", etc., but the important thing is using the number in the field name. With a consistent number scheme for a series of fields like this, you can utilize getfield() to pull the right field value based on an index (which was passed as the script parameter, and assigned to the variable "$fieldNo".) If it's not possible or it creates problems elsewhere to give your fields names like this, then you may be better off with the one-script-per-button approach.

I should add, that if these fields hold similar types of data (like survey questions,) and reporting or statistical analysis of the responses is required on a group of questions at a time, then a different structure would be necessary that puts the responses as separate records in a related table. This would likely complicate the branching of the buttons, however.