There are a few ways to do this in filemaker:
1) Make the memo field have an auto-enter calculation based on the field referenced:
2) Use the Set Field or Replace Field Contents script step attached to a button or other script that puts the calculated value into the destination field
3) Make the memo field a calculation type, with that calculation.
#1 is my preferred method, here's a video showing you how to do that.
In your calculation for:
lnAmount * (lnIntrRate/100) *28/360
just make sure the bolded points are pointing to the correct fields in the same table.
Not familiar with Foxpro (but I'm always happy to hear someone moving from a Microsoft app)...
Filemaker allows you to do calculations in several ways depending on your needs, for example:
1. Create a "Calculation Field" that contains a value that's automatically calculated from other data and updated whenever any of those data sources change values.
2. Create a script that calculates a result and then populates a field with that result.
3. Create a field whose original value is initially calculated (e.g., upon record creation) but then can be changed later on, e.g., with a script or by manual intervention.
There is an Evaluate() function, but I'm not for using it so much. You could still need to Substitute out the constants with the values of fully qualified fields named. Not a pretty sight!
If you have FMP Advanced (and you do), then you may consider Custom Functions. You create a formula and pass values to it.
The other hugely valuable function is the Let() function and it will allow you to assign variables and calculate. It may be used in calculations, scripts where a calculation can be evaluated and custom functions.
There is also a (not free, unfortunately) JDBC driver for VFP which will let you write code to transfer all your VFP data, including MEMO fields, to FMP (or to MSQL, or to whatever DB you want). You'll have to also get the JDBC driver for the target DB (for example, FMP), but if you're a VFP developer (like I used to be), you're used to coding.
Every other JDBC driver including FMP's, MySQL's, SQL Server's, Oracle's, etc., that I know of (except for VFP) is totally free (though FMI sadly cripples theirs so it only works on the same machine as FMP).
Let me know if you have any questions.
the problem is that the equation is not static
here is the link:
OS is also linked to
To calculate payment one need the get the bond type which contains the formula to calc interest payment
Then loop through issues and then maturities to calc the payment for the maturities. They could be monthly for 20 years or so
In vip i have a line
Interestpayment = eval (bndtype.formula)
And all is dandy
Beverly, Ill check out eval in FMPA16
Sure, I understand how VFP's "Eval()" works (and VFP's "&", too), but in my posting I was only referring to the JDBC driver which will connect to both VFP free tables and tables within a DBC and let you migrate that data when you're ready.
You'll have to experiment with FMP's Evaluate function or as beverly suggested, you could write your own function.
Ok, it looks like evaluate does work for this
What could be the objections to it? Beverly seemed to be hesitant
Where is it used? Unstored calc field? Set Field by script?
Sent from miPhone
No calc field
The bond interests calculations are not by a fixed equation i can store in a calc field
They are different for each bond or specifically bond type
What a bond gets issued the bond commission decides how to calculate the interest
The users enter that equation into a text field
On VFP i used a evaluate function to first check the validity of the equation (by evaluating it in the exit code of the text field and rejecting it if there is an error)
There are many different ways to skin a cat or calc a bond interest.
This avoids programmer intervention if the bond commission comes up with yet another way if this would all be hardcoded in an mile long if else if endif statement
I think evaluate() should work in FMPA16
Bw, is anybody going to the connecticut fm users group meeting next week?
Isn't it funny how VFP has almost become a proprietary format? I've used VFP going all the way back to Foxbase+ and it's a great desktop development language. I still support some legacy code for applications written in VFP, but there is no question that it's a dead language.
Filemaker is perfectly capable of providing similar, if not extended, capabilities to VFP, but the conversion issue (both data and code) is the difficult one.
For our distributed desktop applications, we settled on XOJO (using Sqlite database), but for my internal solutions, I still rely heavily on Filemaker because of the speed with which I can get something working.
I remember when everyone supported dbf files, even Filemaker imported directly from dbf files (not sure if that included memo fields), but now, it's extremely difficult to find anyone that imports directly from dbf files.
1 of 1 people found this helpful
You'll have other conversion challenges.
SET ORDER TO has no equivalent in FMP. FMP will not let you quickly change sort orders so your users will wait while things re-sort. Talking about CDX files here. (example: USE TABLE CUSTOMERS ORDER FNAME)
No FXP - compiled PRGs. Whether script performance in FMP will be an issue for you is something you'd need to benchmark.
No inheritance or class files. VFP's property sheet, form inheritance, and class files (VCXs) are incredibly powerful. Nothing like that in FMP.
No EXE distribution model in FMP. This one feature killed any consideration for FMP with my client who STILL USES a VFP 9 application.
No low level file functions in FMP. This application does lots of file handling using VFP's FOPEN, etc. We could work around that with a microservice or an expensive FMP plug-in perhaps.
SQL Performance. In VFP using the Rushmore engine, we have incredible SQL performance. FMP didn't come close in our query benchmark tests vs. VFP.
The VFP app also uses lots of "local error handling" with try-catch. Nothing like that available in FMP.
FMP has lots of cool stuff, to be sure, but for my VFP client at least, FMP was removed from any serious consideration quickly due to the conversion LOE and the huge cost increase to host the application using FMS. That cost increase basically went from ZERO dollars for the free EXE with no royalty costs to FMS' costs for 25 users. No way. So, about a decade after VFP 9 went into the sunset, one of my clients still use it and I still support it.
Using MS's XMLHTTP OLE control we've added tons of other features to the VFP application to keep it current and usable.
This is a public forum so you may not want to share your email and phone number here. Make sure to use the communities’ messaging system next time!
Please send me a PM with any questions and I'll try to help.