Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×

If() vs. Case()


This topic is 7030 days old. Please don't post here. Open a new topic instead.

Recommended Posts

This almost goes in a miscellaneous section. It's a speculative question ...

In vs. 7, both Case() and If() short-circuit

In vs. 7, both produce null on false results

In all versions, both are boolean tests.

The only difference, as far as I can tell, is that If() only allows two options. If this is true, why did FileMaker keep both? It seems that conversion-time would have been perfect to streamline and eliminate one. They could have kept Case() and just re-named it to the logical 'If'.

Are there reasons both were kept that I don't understand?

LaRetta

Link to comment
Share on other sites

Hi Steve,

I considered that but I don't buy it. FM converted everyone's Today() functions for them. And all their Status(Current's) to Get(Current's) etc ...

And vs. 7 is not backward compatible anyway - conversion must take place regardless. It just seemed like the perfect time to combine/eliminate the redundancy. After all, that's what we specialize in. wink.gif

Any other reasons come to mind?

Well I can accept that they just forgot or didn't think of it. I just wanted to be sure there wasn't some reason I couldn't think of to explain it. Because an opportunity to 'convert' the files won't come again. Vs. 7 will open in Vs. 8 I would bet. Lost opportunity ... I guess.

LaRetta

Link to comment
Share on other sites

ease of use probably. Most "simple" users expect an IF function and only discover the CASE later on. Not having an IF function would probably generate a lot of support calls and a chapter on its own in the manual smile.gif

Link to comment
Share on other sites

jester.gif

That's why I mentioned renaming Case() to If() again. I guess that would stress the brain synopsis of many Developers - none frequenting these Forums, of course.

Multiple If/Else makes more sense to me than Case(). And it follows the same logic as script statements (and boolean tests).

Thanks, Wim!

Link to comment
Share on other sites

Unfortunately isn't it either/or but highly dependant on the task at hand if they really should be used:

Down load this:

http://www.filemakerpros.com/Optimizing1.zip

Optimizing Conditions

Conditionals are one of the most commonly used capabilties in FileMaker Pro. Without Case and If statements, FileMaker Pro scripting and calculations would not have any decision making abilities. However, developers use Case and If entirely too much without thinking about how to optimize their functionality.

One of the most basic techniques is to analyze the data and write a script or calculation tailored to the data. For instance, let's say you have a contacts database and you need a calculation that tests all the states in the United States. That's a nested calculation or script with 50 possibilities. So, you create the solution testing each state in alphabetical order and ship the finished product to your client in Wisconsin. What a minute! Isn't Wisconsin one of the last states in alphabetical order? And, aren't most of your clients customers in Wisconsin? That means your solution checks the most common result last. If you had analyzed the data, you could have optimized the conditional script or calculation by checking Wisconsin first. Why test all the other states if the one you want ninety percent of the time is Wisconsin?

This is the inherent problem with Case and If script steps and functions. They have to test every possibility until a true test is reached. Sometimes you have no choice but to use a Case or If statement. If possible, try to use the Choose or Position instead. The Choose statement only requires one test. If you can work your results into a linear progression of number results, the Choose can be a welcomed enhancement. Another alternative is the Position function. Let's say you need to convert letters of the alphabet to a number from 1 through 26. Here is a solution using the Position function:

Position("ABCDEFGHIJKLMNOPQRSTUVWXYZ", Letter, 1, 1)

Rather than testing each possibility with a Case statement, the Position function is used to search a string of characters. Only one search through the string is done which speeds up execution tremendously. This is a simple conditional, but it is possible to use the Position function with more complex problems. For instance, let's say you need to convert Unix dates to FileMaker dates. Unix dates look like this:

--sd

Link to comment
Share on other sites

Agreed. I always use Choose() and Position() instead because they save evaluations.

There are times however, when an If() or Case() test must be performed, if (pun intended) you know what I mean ... wink.gif

I've been wanting to run a series of speed tests - comparing using a Set Field[] with 3 or 4 Case() tests ... as compared to If/Else script-steps. Maybe I'll get that done this week also. Yep, give me some rest and I get frisky!!

LaRetta

Link to comment
Share on other sites

This topic is 7030 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.