4 Replies Latest reply on May 14, 2013 10:02 PM by Fred(CH)

    Text values are always False in boolean context



      Text values are always False in boolean context


      FileMaker Pro


      12 and earlier

      Operating system version


      Description of the issue

      Text values in boolean context always evaluate to False, even if the text is not empty. This is non-intuitive and inconsistent with FileMaker own labels in some dialogs: "The result must be boolean. Non-zero values are true, zero and empty values are false." The label talks about boolean values, not text, but it also mentions empty values and what is an empty value in FileMaker if not an empty string? And if an empty string is False, then non-empty strings should be True; this is how it works in nearly every other programming environment out there. But in FileMaker non-empty strings are also False.

      Correction: Text values may evaluate to true if they contain digits. I.e. texts are parsed as numbers and then the numbers are compared with zero. But in boolean context this is just wrong; it makes no sense.

      Steps to reproduce the problem

      Evaluate the following in DataViewer:

         If( ""; 1; 0 ) & If( "some text"; 1; 0 )

      Expected result

      String "01"

      Actual result

      String "00"

      Exact text of any error message(s) that appear


      Configuration information



      I can check if the text value is empty; but it's not quite convenient.

      Here's an use case. I use a global variable ($$error) to store the last error; it's fairly convenient and I assure you it's not me alone. Sometimes I set it to the last FileMaker error, which is numeric; if there's no error, Get( LastError ) will set this variable to 0 (zero). Zero is, of course, False in boolean context. Sometimes, however, I use the same field to store custom text messages; in this case no error is represented as an empty string.

      If empty strings were interpreted as false values, I could've used a very simple check:

      If [ $$error ]

      to check if there was an error: both zeros and empty strings would be interpret as False and this is exactly what I need. But since non-empty strings are also interpreted as False, I have to use a much more convoluted formula just for this purpose:

        not IsEmpty( $$error ) and $$error != 0

      Of course, I wrap it into a custom function, but it's still very inelegant.

        • 1. Re: Text values are always False in boolean context


               Hi Mikhail,


               I'm the sixteenth reader, but no answer at this time...


               To begin with humour, i wrote this funny formula just for you : 


          Code ( $$error ) > 48


               Now we must return to your idea…


               To have a chance, i suggest your to submit a feature request to FMI. Because i can't figure that actual behavior would be considered as a bug.


               However, i understand perfectly your arguments because i have the same problems than you, in particular on error managements. 


               But sorry, but my opinion is different…


               First, i guess the software cannot be changed at this level. If it occurs, what about existing calculation formulas ?


               Second, even not so convenient, this behavior in calculations is finally… consistant. Even FMP have the more friendly parser i never seen, there are some basics it cannot break. Data types for instance in this case. Text is definitely not a Number. Even dates and hours can be -and are- automatically converted as numbers if needed, text cannot. If we bring your reasoning farther, these examples will return the value 1

          GetAsNumber ("Hello")

               "Mikhail" = MyTable::MyNumber /* Assuming MyNumber is setted to 1 */

               "Fred" ≠ MyTable::MyNumber /* Assuming MyNumber is setted to 1.5 */


               I understood the fact you only talked about boolean context and not about number context. But in all systems, boolean are 0 and 1, that are finally numbers. If we follow you, we will introduce a "special case" for booleans only, that consider any strings as 1. So we will Get this :


          GetAsBoolean ( "Mikhail" ) > "Mikhail" * 10000


               Is it really what you are expecting ?


               No offense to you Mikhail : i always appreciate your posts. But true, here, i think it is, like we say in french : "a wrong good idea".


               Finally, here are my suggestions :


               On boolean context, I often use Length function instead of Not IsEmpty, because it is shorter.


               After many experiencing, even it represent more work, i now standardize my error reporting like this : i always put on my variable both Text (that is more friendly for the end user) AND native Error Number* (that is friendly for me to debug) at the end of the string. And all people are happy. ;-).


               Moreover, i am happy two times because I always can test it easily on my scripts. If ($$error) always works because of the error number on it.


               *When there is no FMP error, why don't use a special code like [-99] ?


               I hope i didn't miss an important shadow on post, but if occurs, excuse me Mikhail.


               Bye, Fred

          • 2. Re: Text values are always False in boolean context

                 I have no hopes that this would be considered as a bug, but truly, it's a very confusing way to treat text values in boolean context.

                 Maybe FileMaker has no Boolean type, but it does have Boolean context, doesn't.it? It has a function to GetAsBoolean() and the labels in formula windows often tell us that the value must be Boolean. I'd say it suggests something, in particular it suggest that Boolean is not exactly same as Number, because GetAsNumber() is a separate function and when we do need a number (e.g. a repetition number in Set Field) the label in the formula window clearly tells us that here the result must be a Number.

                 As it is now, it's at least a problem with the documentation and labels. "Non-zero values are true, zero an empty values are false.", Great, what about "mytext"? It is non-zero, right? And it is not empty, correct? So it must be True? Well, it is not.

                 But the bigger picture is that even if they fix this (rephrase labels and maybe remove GetAsBoolean() as redundant) the current behavior would still be a most peculiar behavior for text-to-boolean conversion. Let's look at other languages. For example, in XSLT an empty string is False and a non-empty string is True. In Python the same; an empty string is False and a non-empty string is True. In PHP an empty string is also False, although they also attempt to enance this and treat a string with literal zero "0" as False. Java is different, for one: if string is "true" (literally), then it's True, else it is False. As far as I remember FileMaker used a similar approach in the past (with variations; a single "t" would also resuit in True), but ditched it for good. To parse a text to convert it into a number and then interpret the result as boolean is a very strange way to interpret text in boolean context. I cannot believe someone would depend on this.

                 As for using $$error. Well, you see it's quite convenient to set it either to a numeric error code or to a string. With error codes I can easily test the error type, e.g. If[ $$error = 401 /* NOTHING FOUND */, ... ] and so on. With strings I can easily provide my own error messages, which I also do a lot. I don't want to use custom codes, because this would require me to have something to resolve them (e.g. a table with messages) and because such error messages cannot be user-friendly: they cannot provide specific dynamic details, only a standard string. It's much simpler to just compose the string you want to show. I thought about using strings alone, but this makes it much harder to check for standard errors.

                 I also cannot agree on using Length() instead of IsEmpty() or not IsEmpty(). Maybe it's a couple of letters shorter, but it is also far more ambiguous: it makes the code look as if I am interested in length of $$error, while I am really not. I'd rather make it longer, but less ambiguous. Of course, the least ambigous way would be no function at all, just the boolean context: If[ $$error ... ] wins by a mile.

                 You see, I'm writing a plug-in and I'm seriously considering to write my own quick function for this :)

            • 3. Re: Text values are always False in boolean context

                   Boolean expressions in Filemaker have always evaluated as a numeric evaluation. If the field has no numeric value, it's False. If it has a numeric value of 0, it's False. All other numeric values are True.

                   FileMaker is rather strange that it will evaluate text for numeric content at all: "5 apples" evalutes as 5--true. "Apples" evaluates a null--False.

                   But that's just restating what you have already posted in more succinct fashion...

              • 4. Re: Text values are always False in boolean context

                     Dear Mikhail,

                     Thank you for your reply. One more time, i really appreciated your last post and all arguments on it. So good for my brain... Even our experiences and opinions are definitely differents, it is not the matter here. And now, indeed, we can consider that all was said about this hard topic.

                     But if you permit, on side way, i just wanted to suggest another formula that could be used in your first example : 

                     $$error ≠ "" And $$error ≠ 0

                     Personnally, i never used ≠ "" instead Not IsEmpty, because, as you, i love words wink and it is the reason why i did'nt thought about it on my previous post. But for future visitors, and because i posted an exotic formula previously, i wanted to indicate that other possible syntax. Moreover, i think it is not so convoluted...

                     Now, i just wish you all the best for your future Feature Request !

                     Bye, Fred