Calculated text fields

[Mike_k]

OK I admit it ... I'm stumped. I'm not a FileMaker professional, merely an enthusiastic tinkerer.

I'm trying to create a feedback system where a series of standard questions are checked. Based on this, those questions answered 'yes' are combined together and those answered 'no 'are ignored. I have created 2 fields per criteria, 'Preset text' and 'preset question'. 

So ...Preset message = 
(if preset question 1 = yes, include ‘preset text 1’ else, blank){cr}
(if preset question 2 = yes, include ‘preset text 2’  else, blank){cr}
….
(if preset question 10 = yes, include ‘preset text 10’ else, blank){cr}

I've managed to get the display of answers based on yes/no, but I can't get rid of the blank lines.

I'm am probably going about this the wrong way, so any suggestions?

thanks

[comment]

It is difficult to understand your question because (a) you don't tell us what the expected result is, and (b) the calculation you show us is not valid Filemaker syntax, so we cannot even tell what your actual result is. As it is, I can only guess you want to do something like:
 

List (
If ( PresetQuestion1 = "Yes" ; "preset text 1" ) ;
If ( PresetQuestion2 = "Yes" ; "preset text 2" ) ;
If ( PresetQuestion3 = "Yes" ; "preset text 3" ) ;
...
If ( PresetQuestion10 = "Yes" ; "preset text 10" )
)

BTW, I see no reason why this should be a "calculated text field" instead of a calculation field with a text result.

 

A better solution, IMHO, would be to have each response as an individual record - do a search for "survey".

 

Edited October 13, 2016 by comment

[Mike_k]

Apologies for not being clearer.
I had a feeling i was going about it the wrong way, so I'll search for 'survey'

thanks

[Michael E. Kupietz]

The above works, but as an alternative:

You were very close. I think what you were grasping for was this...

Preset message = 
if (preset question 1 = "yes", "preset text 1" & ¶,"")&
if (preset question 2 = "yes", "preset text 2" & ¶,"")&
...
if (preset question 10 = "yes", "preset text 10" & ¶,"")&
 

Edited December 12, 2016 by Michael E. Kupietz

[LaRetta]

 

On 12/12/2016 at 1:57 PM, Michael E. Kupietz said:

The above works, but as an alternative:

A few comments:

1. If() does not need a default result of "" and hasn't needed a default result since version 6.
2. I do not believe commas are accepted any more, having been replaced by semi-colons. I might be wrong there however.
3. The List() function adds the carriage return and drops empty values automatically.  It is well worth using.

In all, the calculation provided by Comment achieves the same result in a simpler fashion but I agree that a structure change is advisable. :-)

[Michael E. Kupietz]

1.) Yeah, I know, but I prefer things to be explicit as a programming practice. Purely a personal preference. I always include default cases in Case() statements too, even if they're empty.

2.) Old habits die hard. FM still accepts them when inputting calculations, but converts them to semicolons itself. As long as FM accepts both, it's just a matter of personal preference. I happen to find commas more intuitively readable for sample code. Also a preference because semicolons are commonly used as statement terminators in many other languages (such as javascript on the web, and BASH on OS X's Terminal command line) so semantically it makes less sense to me to use semicolons as parameter separators. For this reason, I do tend to use them, rather than commas, to separate multiple variable declarations in Let() statements, but still not between parameters - like this:

Let (
[
  a = if ( x = 1, 4, 5 ); 
  b = 2;
  c = if ( y = 2, "Z" , "" )
]; ...

...is just much more immediately readable to me than:

Let (
[
  a = if ( x = 1; 4; 5 );
  b = 2;
  c = if ( y = 2; "Z" )  
]; ...

Programmers coming from other common languages will understand the first immediately, the second not so much. Nice thing about FileMaker, there's more than one right way to do these things.

3.) Yeah, but I posted my example not because it was preferable, but because it's what the original poster seemed to be trying to come up with, and I thought it was instructive for them to see exactly where they went wrong in their original attempt.

Although there's really no reason to favor one approach over the other, other than a stylistic preference to write either minimally more compact code or minimally more explicit code. In my own database, I might use list(). In projects where I know the client might want their admin assistant to go in and make tweaks to calculations occasionally after I'm done, I'd use the code that's least likely to result in a phone call to me to ask, "What does this mean?" Beyond that, it really doesn't matter.

Edited December 17, 2016 by Michael E. Kupietz