New to .fp12 / FMP20

Hi all,

my Name is Martin Trautmann, from the south of Germany (black forest). I did not find any hint whether to introduce myself here. But this forum has been recommended to me and I wanted to "warn" you about maybe a flood of questions which I might drop in here.

So please don't hesitate to tell me directly when I have not noticed a previous answer or may have failed to follow the established standards here. Please keep in mind that I'm not a native English speaker and may have to ask or reformulate if I failed to say what I actually meant to say.

About myself: I'm a long term filemaker user. I started with FileMaker Pro 2.1 (.fp) in 1994, used FileMaker 3 excessively and even maintained the FileMaker FAQs within a .fp3 database, which was used to post on news:comp.databases.filemaker .

I've stayed on MacOS 7.6 and .fp3 for ages,
then switched to MacOS 10.3 and .fp7 and became stuck at MacOS 10.10 and FMP11 until the change became inevitable.

So I'm on .fp12 and FMP20 now (yeah, I noticed that there is no version 20 any more, but "Claris FileMaker 2023" instead, but I'll prefer to name it FMP20, ok?)

FMP/Claris lacked to give me any improvements for my actual work. So I never saw any need to change to a newer versions, even less for newer licencing models which did not match my actual single user needs. But FMP11 forced me to stay on MacOS10.10, which became more and more unusable for mail and web.

So please excuse me if I have to catch up with the current release and the long history of changes that happend in between - and me whining about features that I now miss from the ancient history of former versions.

Thanks for your help!
Martin

1 Like

Welcome to the soup!

Enjoy FileMaker development.

2 Likes

Welcome to The Soup!

And don't worry… ask away as much as you want. Someone could point you to a post that answers your question if one exists. Alternatively, you could use the search feature to look for existing posts that could answer your questions.

Don't worry about your English either. Many on this forum are not native English speakers, myself included. Being an international forum, the management team understands and expects that SNAFUs will occur from time to time due to language issues.

Hope The Soup becomes a good resource for you.

2 Likes

23 is a marketing number for the product, to avoid year-of-release confusion with FM20 as the underlying release number. The now deprecated Claris Pro started at version 40. (Glad that is gone now)

There are a zillion major improvements to FileMaker over the years, with Apple's far more active involvement starting with FM19, causing a rapid evolution of product and features, along with significant performance gains.

Scan through the various release notes on this page, per version. Some great stuff in there, at least for more complex solutions.

Thanks - I have been working with FMP for some days now and there's actually very little which feels like a real improvement to me.

For me FMP is a tool to handle data. For that part there has been little to no improvement.

The data import dialog became somehow better, although is now more time consuming when you have the more or less same amount of data, but in different sort orders to import.

I'm actually disappointed that you still can not tell the export dialog whether to use CR, LF or CRLF (Mac, Win or Unix end of line).

The charts offer slightly better options, but are still far behind to LibreOffice Calc (or Excel).

In times of .fp3 I built graphics in font size 1, linespacing 1pt, using actual characters as dots and formulas to build those graphics - and I'm afraid that I still have to go that way. The WebViewer sounds interesting - I wonder how SVG will be fully supported over there.

I've learned about some options that might be interesting - but those are of no actual use to me, yet.

And there's still no "undo" operation for a replace operation that went wrong? I thought I had read about that in the list of improvements, but failed to see that anywhere.

Concerning speed: No, I do not see anything about that. Find and sort takes about the same time than before, while some edit operations feel as if they would need some extra time until they do start, where FMP11 was more responsive before.

So I still feel FMP gets better for things, which actually can be done even better with other software. But it lacks improvements in its actual field of application, to handle (and edit) data.

We could spend a few hours going over all the changes. SoliantConsulting.com blog has a ton of really interesting stuff (I know I refer to them often, but I have no affiliation from them, but have a great deal of respect for Wim DeCorte, the principal engineer there - amazing talent!).

A few of the small things that have great impact, especially in UI/UX.

  • The HIDE calculation - being able to selectively hide or display UI objects.
  • Button Bars - the ability of the label to be a calculated entity is amazingly useful.
  • Slide Controls (vs Tab controls). Combined with a button bar, and object naming, you gain a significant leap in functionality options over tabs
  • Card Windows!
  • Script Workspace - what a major leap forward that was and is over the prior. Auto complete of commands, even using cap letters in camel case defined command names. ( a "G" return, followed by a "APSN" return, will expand to Get (AccountPrivilegeSetName).
  • Color coding of script steps.
  • Adding MonkleyBread's plugin (free version) to the mix, and the developer enhancements grow exponentially. You get radically improved color coding, auto-complete of variable names, undefined variable indications, collapsable code structures, a script check, execute test added to the calc dialog, add or remove TOs from calc structure with a button click, script FIND, relationship diagram FIND, value list FIND, ...... you get the drift.
  • Perform Script on Server starting with FM13
  • The addition of JSON support
  • WebViewer
  • BI-direction web interaction from FM
  • Data API
  • Admin API
  • Claris Connect
  • Claris Studio

And that is just some of the high points - the changes are substantive and extensive, and the pace is continuing to accelerate with Apple's renewed interest in their Claris ownership, pumping resources into Claris.

Oh, and DMT (Data Migration Tool), a command line utility (incorporated in a number of free FM tools) makes off-line development a breeze. Live code is great, but it poses dangers to data. DMT takes, from experience, a 9 hour data migration, to a 16 minute one (really large FM solution),

I wrote this 6 years ago, when DMT was new to the game.

2 Likes

Add to the list the New Layout mode that is quite improved.

All little and no so little things that make developing far easier and more enjoyable.

Oh and the Themes that help making a UI coherent.

I started working with FMPA 12 and would never go back there.

1 Like

Apologies to Windows users, but MBS affords a huge benefit to developers. IDK how far back in the FM release history you can go to use this, but it is invaluable.

2 Likes

Great list of updates/upgrades, @Kirk ! The Data Migration Tool is a huge boost.

And +10 to Card windows, button bars, hide when... etc. Oh, and JSON support.

Plus the scripting (steps and functions) has grown tremendously IMO.

1 Like

@traut
One word of caution moving from older FM version; the default theme from the older versions needs to get swapped out asap. It has numerous deficiencies which cause all sorts of indeterminate issues to show up, especially in WebDirect.

WebD (WebDirect) is light years better and far more compatible than the old fm12 or earlier IWP. Also, the ability to add up to 10 worker servers to FMS each supporting 200 webD users, is a boon to scalability. There are very, very few features of FMP that do not work in webD and they are minor with simple workarounds. “Other” in value lists and z layer objects are 2 prominent limitations.

1 Like

Replace Field Contents may not be the most appropriate way to perform that objective. The reason is that RFC will skip any locked records, with no reporting of that as an error condition.

A better - and equaly performant - way to accomplish this is a loop and a set field. That way, you can check for the open record status for any record, and aggregate the skipped records to be repeated later (or even in the same loop, repeated until complete).

Also as RFC is a single field replacement, a LOOP provides options for more fields to be involved if required, within the same loop. A repeated RFC on a different field has to traverse all the same records again, which is far less performant than a loop.

2 Likes

Replace does tell me that some records may have been locked. For a single user database this problem is doable.

I don't know how a loop could handle that better, other than stopping or highlighting those records - which also does require a second step to process that operation.

I doubt that a loop is faster - for my experience the replace operation is much, much faster. I use the loop mainly to create related records.

A typical replace operation here is to split "data (extra)" to data;extra in fields a;b

Find "(" in field a
replace field contents of b with
substitute(middle(a,position(a&"(","(",1,1)+1,9999),")","")
/* the &"(" is redundant here, but my fallback solution if no "(" is included /
/
the operation has problems with fields including two sets of "()", but those few instances are handled manually afterwards */
replace field contents of a with
trim(left(a,position(a&"(","(",1,1)-1))

Calculations are entered by hand,
more frequently used calculations are within a BBEdit document for copy/paste

I don't see that much of an advantage to put this into a scripted loop. Would the loop now permit me to open a set field, by calculation dialog directly? I did not check that yet - the former script behavior would permit a set field dialog only, requiring an extra step to enter the by calculation window. Apart from that it would require some extra handling to take the set field dialog for the active field, which would not have worked very well in .fp7. Is that easier in FMP20 now, too, to select the active field for a set field scripted solution?

My other, typical workflow is to copy a column from my spreadsheet document to vim (or BBedit) and use regular expressions
s/ ((.))/\t\1/
and copy/paste that back to the spreadsheet. That's where I still hope for better spreadsheet like operations within FMP. Instead I have to go via export/import here.

Benchmarks on RFC vs loop almost always produce a virtual tie on performance. If a loop hits a locked record, you can trap that value and hit it again. No such capability in RFC.

There is also a performance “trap” in RFC if you attempt to RFC across more than one related child TO. The relationships ( FM relationships are, in effect, queries ) get evaluated with each replace which add tremendous performance impediments. (There might be other factors as well). I replaced a number of multi-TO spanning RFCs with a context switch and a find/replace construct and gained well over a 10x performance improvement.

There are a lot of custom functions available for FileMaker that use regex. You could write your own if this is a common action. Search Google for regex in FileMaker.

If performance is critical, check out the new WHILE calculation. VERY fast. Recursion is now far easier to implement.

Also, as a general analog, scripts run as if an interpreter; calcs run as if compiled. The performance different is significant.

I’ve used spreadsheets since the 70s visicalc, been a beta tester for Lotus 1-2-3, and created thousands of spreadsheets. I have never seen anything in any of these tools that can’t be done in FileMaker and most of the time, easier.

Thanks, I'll try some benchmarking myself. I can't believe your results yet.

What you consider as a disadvantage, for me usually is an advantage:

A loop has difficulties to replace contents of 1:n related records. You need nested loops and portals to actually see all of the other matches- A replace operation does treat all related records the same.

Concerning nothing better than FMP:

I frequently collect data from website or PDFs, sometimes several thousand records, at about 10 to 50 columns. Those grabs usually have plenty of gaps, such as

A 1 11.5 B C
B 2 10     D
C 3      X YZ

During import those empty fields become shifted leftwards, since empty fields are just blank space.

In a spreadsheet it's rather straight forward to sort records by columns and shift areas of spreadsheets rightwards to the proper columns again. But shifting data from field to field to field in FMP ist just cumbersome.

So I usally do the the shifting in a spreadsheet and only after the import to a FMP database - and it's annoying that FMP still suggests a $FILENAME converted, instead of converting a DATA.xls to a DATA.fp12 . Personally, I prefer to use the same filename for both. That's what the file ending is for, to differ an excel and an filemaker file.

To my surprise FMP did not accept a .txt file to be dropped on it. It does not know what to do about it. I had to rename the .txt to .csv. But a significant improvement: it now accepts both comma, semicolon and tab separated import files. No more need to convert a .csv to a .tab first.

Another advance I forgot to mention is a few new commands that support indirection making for portable and modular code.

Set field by name

Is one very useful and common one.

Oh, and UUIDs in place of serialized keys. Major improvement especially for untethered FMGo solutions that have to sync back to the server.

Did you know that new versions of FMP allow more than one search/replace expression? You can now pass a large number of replacements in a single call.

Substitute ("text" ; [ search ; replace ]  ; [ search ; replace ]  ; [ search ; replace ])

I am guessing that you don't know what actions are required in Vim or BBEdit, otherwise this step could be automated. A few simple command line scripts make it easy to clean up known problems.

Have you tried the command line tool called cut? It may be able to make sense of your messy data.

That's not new, but could be done the same way before.

So there is no improvement to the syntax

substitute(field;
[ expr1; expr2];
[expr3; expr4])
etc?

That has been illogical from the beginning on. You don't need a
case(
[if1;then1];
[if2;then2];
else),

you don't need
let(
[x=a];
[y=b|;
x&y)

Substitute should work with
substitute(field;
[ expr1; expr2;
expr3; expr4])
or without rectangular brackets at all. Never liked them for substitute.

I am guessing that you don't know what actions are required in Vim or BBEdit, otherwise this step could be automated. A few simple command line scripts make it easy to clean up known problems.

I don't know what you guess, but my calculations change all the time. Sometimes it's "field1 (field2)" or "* field1 * field2" or "field2, field1" etc. So I don't know how you would like to automate that.

Have you tried the command line tool called cut? It may be able to make sense of your messy data.

I don't know how cut would help for my purpose. Take e.g. 20 pages pdf, printed from any kind of table documt. I use pdf2text -table to get the text info back. So each page has its columns at a different character count and not all columns are filled.

Was that change in place before v12? I have forgotten when they introduced it.

No, there is no change.

I guessed that your calculations change, and the changes prevent you from automating the editing process.

It does depend on the data you have. I've found that cut is very smart with space delimited data. I mentioned it in case you did not know about it.

Another tool that is good for cleaning up data is OpenRefine. It has a good toolkit. The entire history of operations that you perform is stored with the file, so you can redo/undo them at any time.

The substitute command was introduced in FMP 3,.0

At some point in time they improved the function to allow many substitutions a single call.