Re: Calculated Value Wows..
While I am sure everyone here knows this;
A Calculated Field is a calculation done on a field at the table level.
A Calculated Value is a calculation done on a form and even though the A5 developer calls it a Calculated Field, it is not.
This is the first time I have tried using calculated values on a form. Most of the time I use vars or table fields and do the calculations in scripts and some in-table calculated fields.
Scripts have to be triggered to run and calculate, calculated fields need something in the table to change in order for a calculated field to recalculate. Calculated Values on a form will recalculate anytime the record is committed.
So each method needs something to happen before the calculations will recalculate. I have no issue with this.
While I could just take the code from a calculated value and place it in a script it would not be the best thing to do. Using it in a script I can streamline the logic to make the code execute faster based on current logic.
I just tried the Calculated Values to see what would happen and if there was any benefit to using them and I do not see any.
What prompted this thread was not whether to use Calculated values or not but to discus the strange problem I was having getting a Calculate Value to be written to a table field. The strange thing of it working for a while using one line of code and then quit working and having to use another few lines of code. And every time it would quit working all it would take is to swap back to the line of code that quit working before. So just switching two sets of code back and forth every time it would quit working.
As for "Why 100 lines of code", well I was being conservative. My apps are not the common run of the mill product sales and invoicing type systems where you have products you pick and they have a price assigned to them. In the industry my apps are designed for each product can have literally thousands of different price possibilities.
I am with Dave on this so I will be changing everything back over to scripts and functions. I was just trying to see what the deal was with Calculated Values. I see them as a possibility if you only need that calculation done on a single form and not using the results anywhere else. Other than that I can see no use for them.
Now all that said, FlieMaker handles them very well as Calculated Value on a form is in reality still directly tied to the calculation being done at the table field level. In other words a Calculated Field. There is no difference between the two in FileMaker. But I do not really like FileMaker.
While I am sure everyone here knows this;
A Calculated Field is a calculation done on a field at the table level.
A Calculated Value is a calculation done on a form and even though the A5 developer calls it a Calculated Field, it is not.
This is the first time I have tried using calculated values on a form. Most of the time I use vars or table fields and do the calculations in scripts and some in-table calculated fields.
Scripts have to be triggered to run and calculate, calculated fields need something in the table to change in order for a calculated field to recalculate. Calculated Values on a form will recalculate anytime the record is committed.
So each method needs something to happen before the calculations will recalculate. I have no issue with this.
While I could just take the code from a calculated value and place it in a script it would not be the best thing to do. Using it in a script I can streamline the logic to make the code execute faster based on current logic.
I just tried the Calculated Values to see what would happen and if there was any benefit to using them and I do not see any.
What prompted this thread was not whether to use Calculated values or not but to discus the strange problem I was having getting a Calculate Value to be written to a table field. The strange thing of it working for a while using one line of code and then quit working and having to use another few lines of code. And every time it would quit working all it would take is to swap back to the line of code that quit working before. So just switching two sets of code back and forth every time it would quit working.
As for "Why 100 lines of code", well I was being conservative. My apps are not the common run of the mill product sales and invoicing type systems where you have products you pick and they have a price assigned to them. In the industry my apps are designed for each product can have literally thousands of different price possibilities.
I am with Dave on this so I will be changing everything back over to scripts and functions. I was just trying to see what the deal was with Calculated Values. I see them as a possibility if you only need that calculation done on a single form and not using the results anywhere else. Other than that I can see no use for them.
Now all that said, FlieMaker handles them very well as Calculated Value on a form is in reality still directly tied to the calculation being done at the table field level. In other words a Calculated Field. There is no difference between the two in FileMaker. But I do not really like FileMaker.
Comment