It's style. I do it that way because it makes it easier for me to write/debug a calc that way. I generally write calcs in the Data Viewer. This calc is pretty simple, but if it were more complicated I could drop different calc variables outside the variable declaration and see if the result matched my expectations. For example, I could have written the calc the following way, and if it wasn't returning the right result, debugged it, by, say making sure the "too.long" variable was correct: Let([ len = table::lengthRequested ; standard.lengths = List ( 22.25 ; 22.5 ; 25.25 ; 25.5 ) ; max.length = 25.5 match.length = not isEmpty ( FilterValues ( standard.lengths ; len ) ) ; too.long = len > max.length ; result = Case ( match.length ; 10 ; too.long ; 20 ; 0 ) ]; //result too.long )
You can run FM 13 and FM 14 simultaneously on one machine. FM 14 files will run in FM 13, except for FM 14-specific features (for example, the new Top Navigation part will show up with a big red "X" in FM 13). I don't think there's an Advanced version for demo, but I'm not sure.
OK, but which one will be left empty? Will a user leave a search global empty or will the contact record not have a value for a field? I'm guessing the user may not enter a birthdate when searching, but I want to confirm that.
I think the simplest would be to make a summary field in the Inventory table summing the costs. Then put a single row portal on the layout showing that summary field and filter the portal where inventory::relatedService =/= Service::Name. That should work...I haven't tried it with a relationship that's two "hops" away though.
I apologize. I didn't mean it as a challenge. I'm just trying to understand something. I've heard several runtime developers express the sentiment that deprecating runtimes in future versions of FileMaker is bad for FileMaker. That runtime developers are important to FMI somehow. Clearly the deprecation is bad for that developer. I get that. And even if it won't actually affect anyone for 2-5 years (time until deprecation + time until OSes become outdated), it's usually hard to face the mortality of something. I'm not a runtime developer myself so I don't feel the emotional punch. It's not clear to me why someone would think it is bad for FileMaker itself. As comment mentions, we can only pretend to know what's good for FileMaker. I think it's extremely likely that FMI has actually thought this through, run the numbers, and decided rationally that runtimes aren't worth supporting anymore. I don't understand why runtime developers say it's a bad decision for FMI. Or why they're an important subset.
The "starting from" table should be the table that the layout you're putting the menu on is based on. Probably Projects. I'm not 100% sure about your naming convention, but I'd say you should relate CategoriesSub 2 to Projects based on Category_Relation -->CategorySub_Relation. You'll have to delete the current relationship to make the new one. Once that relationship is in place, the value list should work as you've defined it.