Calculations Outside Fields?

[Mr.Bill]

Hello- Total NB to FileMaker, but really great product! Question: Is it possible to do a calculation outside of a field. Example: Is there a trick within a standard text box? Thanks!

[Lee Smith]

Hi Bill,

Give us an actual example of what you are wanting to do.

Also, check out the [color:blue]Insert in Layout Mode, the Text Operators (Online Help), particularly the Concatenate.

Lee

[Mr.Bill]

Hey Lee- Thanks for the quick reply.

I want to be able to make a simple arithmetic calculation of 2 fields.

Example: FieldName 1 * FieldName 2 =

I don't need to keep track of the result for anything. Its just for the viewers reference. I wouldn't mind creating the field, its just that for each layout, there are well over 200 and this creates a lot of fields.

In the meantime, I will look at your help suggestion. Thanks again!

[bcooney]

You are hinting at something that sounds very much like it should have been created in Excel. In FileMaker, each calculation is a field. Are you creating a layout that looks like a spreadsheet?

Or, perhaps you ought to be creating a subsummary report. Have a look at the help topics for that.

[Lee Smith]

Or relationships.

I'm still not grasping what you are trying to do, but maybe when you respond to Barbara's post it will be more clearer.

Lee

[comment]

In FileMaker, each calculation is a field.

Not quite, strictly speaking. You can have a calculation in a script, and present the result on demand in a custom dialog. Or in a tool tip. Or in a web viewer. Or in the Data Viewer, if you have Advanced. Basically any place that has a formula box - even in a window name.

You can also have multiple calculations in a single field (or any one of those other places). There are endless options here, and a clarification is definitely needed.

[Mr.Bill]

Hello- Thanks for all the attention.

You are correct, this is very spreadsheet like. I would create this in excel, but it needs more of a DB behavior and in this case, FM seems to be the best fit.

To help clarify, its a pretty basic DB that is very financial solution focused. The user enters numeric data, and the database reacts with giving the results of the data that has been inputed. There needs to a be multiple records as well as published to the web. Thus the reason why FMP fits the bill. I do like the idea of 1 calculation cell acting as 5 calculations. This would cut all the required calculation fields down by 5 which is a huge help.

I'm also going to look into the other suggestions.

Thanks again for the assistance!

[bcooney]

Yes, Comment, I know. But the OP said that he didn't want to store the results, just display them. I was thinking he may be familiar with other systems that allow for layout-only calculation fields. No matter how you derive the calc, the result needs to be in a field (stored or unstored).

[comment]

An unstored calculation field does not store the result (hence 'unstored'), only the formula - very much like an Excel formula cell.

[bcooney]

Ahh! OK, you got me. It's in a field though. :

[CobaltSky]

As Michael mentioned in his earlier post, there are various options available, including some that don't require any calculation fields in the schema.

See attached example. :

CalcsWithoutFields.zip

[comment]

Hey Ray, good to see you around again.

All the other options nonwithstanding, I still don't see what's wrong with using a field.

[CobaltSky]

Hey Ray, good to see you around again.

Thanks! I had some stuff to deal with - but it's good to be back.

All the other options nonwithstanding, I still don't see what's wrong with using a field.

"Wrong" might be too strong a word - but it seems Mr.Bill has hundreds of calc results to display but was hoping for a way to keep the schema clean and simple. I guess I can sympathize - hunting around in export or sort dialogs (etc) is not much fun when the fields number in the hundreds. :

[comment]

If that is the concern, they can be reduced to two fields. Actually, it could be done in a single field, but that would be less convenient to manage. I don't know what this is about, but I think fields are the first choice for calculations.

TwoFields.fp7.zip

[Mr.Bill]

Hello Everyone. All your suggestions are very much appreciated. I am going to try these different ideas and see what happens (I'll report back).

As for why am I trying to avoid using fields, its simply a matter of keeping the foundation tight and manageable. Basically KISS :.

Looks like it will be field based, but I am going to try some of these ideas.

Again, many thanks for the great support!!!

- Mr. Bill

[bcooney]

I appreciate the "thinking outside the box" technique, but this isn't an approach that I would recommend. I feel that the hard-coded field names in the calculation are too "fragile." Just imagine changing one field name and not realizing that you just broke all dependent calculations.

I was aware that calculations do not need to "live" in fields, but honestly, someone who is mimicking Excel will most likely need the results of the calculations to be in fields, for export, charting, etc.

I should preface my declarative statements, I suppose, with phrases such as, "there are many ways, but the method I would suggest..."

[comment]

Which technique used hard-coded field names?

[CobaltSky]

...this isn't an approach that I would recommend.

I believe you are engaging in something akin to a knee-jerk here, bcooney.

To begin with, you've not bothered to check that there are, in fact, no hard coded field names in the file you're commenting on and *nothing* breaks if you rename any of the fields.

Moreover nobody has said that *any* of the approaches under discussion here are suited for all cases - only that they are possible. So you appear to be contending a point no one else has made.

But since you've raised the matter, let me be clear. The idea that fields are the only rightful place for calculations is complete nonsense. Putting calculations into scripts (that, for example, display the results in custom dialogs or post them into global fields) is perfectly legitimate (though not recommended for *all* cases either). Putting calculations into conditional formatting (eg to show flags or highlights or text on certain conditions) is also completely legitimate. The fact that you can't export the results of calculations in scripts or conditional formatting - or reference them when creating charts - may be a factor in deciding when to use such techniques, but does not discount them, any more than it discounts the use of calculations in Web viewer objects. :Whistle:

[bcooney]

You're right. I spoke too soon. I didn't realize that the webviewer is using the specify calc dialog. As the church-lady would say, "Never mind."

[Mr.Bill]

Hello and Happy Holidays,

Thanks for all your help. I've explored various ways and due to my current FMP ability, I am going to just create a whole bunch of fields for now.

I tried creating repeating calculations fields, but got stuck how to dcreate a different calculation for the different repeated fields (sub field).

Anyway, again, thanks!

- Mr. Bill