11 Replies Latest reply on Mar 18, 2016 4:56 AM by disabled_morkus

# Simple Calculation - I guess...

Hello FileMaker Land

I am sure to all of you that work with FM on a daily base - this is too simple... anyhow here is my question. I'll be glad if someone could share some thoughts on this.

I have a 3 number fields

1 km_start

2 km_end

3 km_driven

on the km_end number field is a calculation watching over the entry into the km_driven field. something is entered it will update as normal. All fine here - however I would love for the km_driven field to be updated when a number is entered in km_end. Hence being able to enter either field (km_end or km_driven) and having the correct data available in both fields.

Any help or thoughts on the subject is greatly appreciated.

Happy FileMaking

• ###### 1. Re: Simple Calculation - I guess...

One of two things

1) Make the field a calculation field

2) Uncheck do not replace existing value

• ###### 2. Re: Simple Calculation - I guess...

hi greatgrey...

which field are you talking about..?

sorry - some text got cut.

the km_driven field is just a number field - if I change that to an auto-enter calculation it shows a negative km_start

• ###### 3. Re: Simple Calculation - I guess...

Calculation could be somewhat like this:

If ( not IsEmpty ( km_start ) and  not IsEmpty ( km_stop ) ; km_stop - km_start ; Self )

Cheers

• ###### 4. Re: Simple Calculation - I guess...

km_driven

use an If

such as

If ( start > end; ""; end - start)

• ###### 5. Re: Simple Calculation - I guess...

Ok - that only works one way... entering km_end data will result in the km_driven update - all good so far.

entering data into the km_driven will leave the km_end field empty, which is not what I am after...

any ideas ?

• ###### 6. Re: Simple Calculation - I guess...

Same logic for km_end:

use another auto enter calculation with "if"

• ###### 7. Re: Simple Calculation - I guess...

Got it sorted - Thank you guys sterngucker for pointing me into the right direction...

• ###### 8. Re: Simple Calculation - I guess...

The calculation only seems correct. You cannot change "end" or "driven" afterwards, as there will always be a values in one of both fields.

I would use two inputfields for "end" and "driven" (number), with calculated results and an alert to only enter either kom_end or km_driven:

km_end =

Case (

not IsEmpty ( km_driven_input )  and  not IsEmpty ( km_end_input ) ;

TextStyleAdd ( TextColor ( "Enter only end or driven !" ; RGB ( 255 ; 0 ; 0 ) ) ; Bold ) ;

IsEmpty ( km_driven_input ) and not IsEmpty ( km_end_input ) ; km_ end_input ;

not IsEmpty ( km_driven_input ) and IsEmpty ( km_end_input ) ; km_start + km_driven_input ;

)

km_driven =

Case (

not IsEmpty ( km_driven_input )  and  not IsEmpty ( km_end_input ) ;

TextStyleAdd ( TextColor ( "Enter only end or driven !" ; RGB ( 255 ; 0 ; 0 ) ) ; Bold ) ;

not IsEmpty ( km_driven_input )  and  IsEmpty ( km_end_input ) ; km_driven_input ;

IsEmpty ( km_driven_input )  and  not IsEmpty ( km_end input ) ; km_end_input - km_start ;

)

• ###### 9. Re: Simple Calculation - I guess...

It look like maybe a script and script triggers on the 2 fields is what is needed.

• ###### 10. Re: Simple Calculation - I guess...

Yes, rather than trying to write code first to handle situations, document all the situations first, then write code.

So, in this case, document all the possible ways you could enter km_driven and other values with the expected results.

Then, trying to write logic is much easier.

FileMaker encourages you to "jump right in" and start coding, but that's not the best way to proceed.

Think first, code second.

- m

• ###### 11. Re: Simple Calculation - I guess...

To further clarify my reply above, when you create a formal description about what a feature should do (in words, written down), plus when you document (say in a matrix) all the possible calculation cases, the code will usually fall into your lap. Some languages also encourage "pesudo-coding".

Plus, this more formal approach will help you discover "edge cases": cases where a variable has an unexpected value, or help identify other strange result cases.

I've seen many projects fail (I'm not using your posting as an example, or FileMaker projects in general), where developers jumped in and started writing code before they had a clear idea what they were doing. What usually happens in cases like these is that everything is OK for a while, but then it's oops, start over, (hashing, and often, project failure).

Think of building a house. The construction metaphor is completely appropriate to writing good code (even something as simple as what you're trying to do). You'd never let someone build a house for you without blueprints, so why write code without a formal description and documented cases?

This documentation technique scales all the way to developing enterprise applications.

Best yet? Possibly counter-intuitively, this technique will SAVE you time overall not take more time.

HTH

-m