I would have sworn that I had done this before, but my testing now appears to fly in the face of my memory.

 

Here's some test code to demonstrate:

Let ( [
   _string = "Blah" ;
   _num = 1;
   _num2 = "1"
] ;

if ( _string ; "true" ; "false" )

)

To run the test, you just change the logic clause of the IF statement to be one of the variables at the top of the LET statement.

 

The two 'number' values/strings evaluated to TRUE.  But the string evaluated to FALSE.  I would have sworn that I have used the definition of a string as a logic control before to see if it is set...but I guess not. 

 

If you change the string value to "1blah" then it will evaluate to TRUE.  So apparently logic checks are working purely on a number datatype (it is my recollection that a string with numbers in it, when used as a number, will just drop all of the alphabetic characters and leave whatever the numbers were in the string).

 

Not much of a question here, perhaps just a verification of my testing above, or your own experience.  Seems like the primary option for checking if a string is defined is to use "IF ( string ≠ "" ; TRUE ; FALSE ) ".  Was just trying to save a few typing strokes. 

 

Thanks,

C

Basically,  it works the way you have described:

If ( text ; ... )

is evaluated as =

If ( GetAsBoolean ( GetAsNumber ( text ) ) ; ... )

which means that the text must contain at least one digit other than zero in order to evaluate to True. Other data types are treated in a similar fashion, with the exception of container fields where =

If ( container ; ... )

is evaluated as =

If ( not IsEmpty ( container )  ; ... )

which means that a container field that contains the text "blah" will evaluate to True.

 

 

 

Seems like the primary option for checking if a string is defined is to use "IF ( string ≠ "" ; TRUE ; FALSE ) "

 

Actually, it's best to use the dedicated function IsEmpty().

I have also seen some developers use  If ( not Length ( field ) ; ... )

 

I do not believe the technique could fail and it is shorter to write but I find myself shying from it simply because it can muddy the purpose.  I have to question the meaning of calculations sometimes (written by other developers or newbies alike) when Length() has been used whereas using the proper function for the job to begin with removes all doubt as to the purpose.

And of course IsEmpty() would be faster if the field contained quite a bit of text which Length() would need to count.

And of course IsEmpty() would be faster if the field contained quite a bit of text which Length() would need to count.

 

I wonder if anyone has ever tested this. I mean IsEmpty vs. Length with short text, as opposed to IsEmpty vs. Length with long text.

Well I am surprised.   With 35,000 records in version 13, restarting between each test.

 

FieldA has average 2-7 words

 

IsEmpty:  1574

Length:  1553

 

FieldB has 10,660 random character words

IsEmpty:  1637

Length:  1608

 

Script was simple:

Set Variable [ $$start; Value:Get ( CurrentTimeUTCMilliseconds ) ] 
Go to Record/Request/Page [ First ]
Loop
If [ not IsEmpty ( data::FieldA) ]
Set Variable [ $$tick; Value:1 ] 
Go to Record/Request/Page [ Next; Exit after last ]
End If 
End Loop
Show Custom Dialog [ Message: Get ( CurrentTimeUTCMilliseconds ) - $$start; Default Button: “OK”, Commit: “No” ] 

... changing only not IsEmpty ( data::FieldA ) to Length ( data::FieldA ) and then repeating changing to FieldB.  I repeated all four tests 5 times each.  I realise I had the Go To within the If but all records had a value so I didn't correct it.

 

the more I think I know ... the littler I really know 

 

Edited:  Added last sentence

And ... when I run the two large tests in 12, it takes 30-50 longer.  But even more surprising is that in 12,  Length is slower than IsEmpty() by average of 50!

 

Here is the file if anyone wishes to come up with their own :-)

 

TestLength.fmp12.zip

Wow, this is great!  I love it when a community comes together! 

Ah.  And I just remembered where I have seen Length() *fail when used this way ... a number field and test of  Length ( number ) > 0 expecting to find all positive numbers and the failure to recognise that a 0 in the field would evaluate to TRUE thus finding more than they bargained for.  ;-)

 

I agree, Cronk, forums ROCK.

 

* of course it is not the function's failure but rather the developer's lack of insight.