My Hopes for "FMP 20" and Beyond

My list of missing FMP features is below. Due to the minor incremental "upgrades" in recent versions, I would need to see something much more innovative before plunking down another nickel. To me, many of the items below are version 1.0 functionality.

Except for the internally-missing features (most of what's below), I've been able to work around all the missing items with micro-services. Still, FMP seems like it needs a lot of new features and making existing features much easier to use in at least some cases.

Short Missing Feature List

  • Version 1.0-type functionality missing: No application-wide search/replace in scripts and CFs

  • Pop-up assist missing other than in scripts

  • No CF code debugger

  • No ISO 8601 standard date formats

  • Only minimal date function support

  • Some tools cannot change fonts or grow window panes

  • No way to get value list from SQL

  • No way to create layout from SQL

  • Missing user goals for export after SQL (relevant buttons for export types, etc., next to where these actions occur)

  • Sorting not stored as indexed file requiring re-sorting each time.

  • Missing basic search/replace in scripts and custom functions.

  • Missing global “find in database” convenience (search all tables)

  • Windows overly modal (have to often close several windows to get menu options to work)

  • No field search in database designer

  • SUM, AVG, and other calcs don’t work on same table.

  • Email SMTP dialog does not suggest ports as you change for encryption

  • No formal NULL concept

  • No intelligent PDF graph layout.

  • No way to programmatically disable a control

  • Missing modern controls like spinners, status completion percent, etc.

  • Data ambiguity problem: only allow users to enter date via calendar

  • Missing: an option to recall a deleted record.

  • Missing: an option to export headers with standard CSV export (must use workaround: Merge)

  • Missing data type inference when importing data (all text)

  • Missing DOC or DOCX export

  • Missing searching binary fields in containers

  • PSOS not debug-able

  • Currency format defaults to “%”

  • No input masks for data entry

  • Reading from file not supported in Web Direct or runtime

  • No inexpensive deployment option for a workgroup (APP or EXE).

  • Runtime deprecated with no replacement

  • Missing: a way to integrate GitHub or SVN

  • Missing object orientation, no way to send message to control or other object

  • Missing native regular expression support

  • SQL select only in native product

  • Missing database triggers

  • FMP JDBC driver needless crippled so only runs on same computer as FMP

  • JDBC driver buggy. Reports go unfixed

  • No FMP bug database available

  • CFs are not global across FM applications requiring configuration management

  • CFs have no pop-up support. No font, debugger, or window pane size control

  • Missing SQL editor

  • Missing ability to do SQL that does not reference something in the relationship graph (select get(CurrentDate), for example)

  • SQL date incompatible with FMP date type

  • Missing concept: SQL Cursor

  • SQL Like queries very slow

  • SQL GROUP BY queries often hang the machine or are otherwise extremely slow.

  • Missing formal indexed array type

  • Missing XPATH support for JSON (to extract, list, …)

  • Missing: XPATH support for XML

  • FMP JSON’s implementation has year + bugs yet to be fixed (periods in object names)

  • Missing: User-definable data structures

  • Missing: fields not bound to a database field (unbound fields for ad-hoc data)

  • Missing: localized error handling (try…catch)

  • Missing: CSS styling for page

  • Missing: expert mode for scripts (dialog-driven development currently only)

  • Missing: script compiler (scripts very slow)

  • Missing: built-in way to save often used script snippets (need to rely on 3rd party tools)

  • Missing: multiple script parameters

  • Missing: multiple buffering modes

  • Plug-ins very expensive to full in functionality holes

  • Slow to update calculated fields

  • Multi-version Design Flaw: Watch expressions in volatile plist file so when FMP crashes, all watch expressions gone.


I can subscribe to every point except for plugins. There are free plugins and most plugins are quite affordable. The plugin conncept is a well-proven and established in software world. The platform vendor cannot take care of every detail and functionality. That's where plugins come in handy. I would be glad if FMI/Claris would cover those points that cannot be managed via plugin instead of focussing exclusively on new stuff while leaving potholes behind.


I was thinking about plug-ins like MBS which is, as I recall, about $600 per server. Instead, I've always coded these "functions" myself however for free.

I've also had mixed results with the free plug-ins including vendor support. My clients have reported Java issues with one or two of the other free plug-ins (not well supported by vendor) making them unsuitable for production use.

I think quite a few of those can be held with MBS Plugin.

Even without a license, you can get the search for script and field list.
For MacOS click on the lists, press Command-F to show find bar.

MBS is a fine plug-in. That was never in question. :slight_smile:

AFAIK, there's no method/function in MBS to allow searching of all scripts and CFs, right? GitHub support? Speeding up GROUP BY queries (since you're still stuck with FMI's JDBC driver), etc....

IAC, my posting was about FMP itself, not plug-ins.


1 Like

You could email me and I could offer you a trial license to play with the plugin a bit more...

For all the external items (like JSON, XML, date handling and such), I've already written micro-service methods (about 150 of them) that work with any HTTP application (NOT just FMP as with a plug-in) -- all for free with one user or 10,000. Local, remote, server, still all free, fast, and easy to extend.

Above (my hopes for FMP 19), I was talking about missing items in FMP itself, not items I've worked around with micro-services and such.

As I recall, you don't offer extensive date manipulation methods in MBS. My micro-services do extensive date handling already for any application (again, not just for FMP). I add new methods as needed and thus don't need to rely on third party software vendors.

As an aside, I recently had a client move away from FMP to a full-stack approach. Since that client used micro-services and not single vendor-only plug-ins, their code investment was intact. Data moved to SQL Server, JDBC code from micro-service only updated to use new connection, other code no modifications, etc.

However, again, my posting was not about plug-ins. :slight_smile:


Very good list! Thank You!

1 Like

I believe the feature set for 19 has been shown publicly. And also on the Roadmap. So there isn't much else besides what they have shown, that I'm aware of. They are in the middle of a core change at the company, and moving to a new release cycle. Bigger changes are coming.

1 Like

There are some nice suggestions here - perhaps one or two will make it into FM19 (but probably no more than that). To be fair, I don't think the 'Missing' category is quite that. I expect some may be added at some point; most, probably never.

There are however features which are 'missing' and which should really be added, eg:


I expect this missing feature has cost at least hundreds, probably thousands of hours of developer time in implementing workarounds (and much time spent by developers coming up with some ingenious workarounds). You don't have to be too pedantic to consider something is less than ideal about a list such as:
Of course you can create a static list, but if you need these items to be stored in a table, you have to be a fairly experienced developer and spend time comparing clever solutions before you can achieve a satisfactory result.

I have no idea if this is a minor oversight which could be fixed in an half an hour or if it would be a massive undertaking which will never get undertaken; I imagine it's something closer to the former.

I think the trouble is, features like this probably aren't great selling points, so they're forgotten about. Fixing this and perhaps making the Script Debugger usable in Windows would make me happy if that was it for FM19.


@anon45965781 Your list is quite extensive !

Due to the nature of FileMaker. my guess is that some of your wishes can't be fulfill , for example:

No way to programmatically disable a control
Missing object orientation, no way to send message to control or other object
Missing global “find in database” convenience (search all tables)

If past is significant for the future, not a lot of functionalities are added each year, then to go throughout your list would require decades.

Compared to other products, FileMaker lacks a lot, for examples controls and you mentioned that. My wish list is very short: make it work first. Reading the official Community, a lot of issues plague V 18. I have not worked with 18, but I worked with 17 and was not impressed by FMS 17 where a lot was lost with the console. FileMaker Inc. had a hard time repairing bugs, I hope the same will change with Claris. On Windows there is a bug that has been there for a while with the drop-down lists where items height are too high for example in the Inspector.

This year we had a different Rodamap presentation in that what's planned for 19 was not developed.

And there are also the never ending changes to Licensing. Each time it gets harder to understand. On top of that, a lot of people feels FileMaker is quite expensive - I don't want to start a new discussion about this.

Enough said for the moment.


Well put, you added lots of good context and information I did not know. :nerd_face:


1 Like

That's quite a list. Some things, like the adding headers for CSV export, have bugged me since the earliest versions.

1 Like

But, do we really want engineers spending time on stuff like that? Not that I don't think they shouldn't at some point, but I would rather they do things like move away from webkit and IE as the engine for the Web Viewer.

It is just so easy to work around. And in other languages, it's not even a work around, it's just how it's done. I almost never do an export raw from the data. It ends up in a Virtual List, and I just make the first row the header names.


What would be different about this one vs just using Hide Object When?

Well in (most ?) other languages, you can disable a control - the same as Field Entry not checked for Browse Mode - and enable as you wish at run time. That would let us use the same layout or tab for both read only or editable data by simply enabling or disabling edit.


I picked that one because the functionality already exists with Merge format export. The engineers would really only be adding a checkbox option to the dialogue and forking to export with or without headers.

I can train users to use Merge but the training has to stick ( or be repeated ). I'm not going to train users to generate virtual lists and I'm not going to argue the merits of a built-in method versus roll-your-own virtual lists. Let's just say that it would be nice to have.



Just the other day I was chatting with a friend about programmatically disabling controls.

Here is a quote of what I said:

I used to always want:

  1. A new layout object state (in addition to "in focus", "hover" etc.) called "disabled"

    • We could then use Inspector to style this as we like and save as a Style in a Theme

    • This state would have additional behavior: Fields Inputs become unusable/non-enterable; Buttons do not click or display their usual hover effects

  2. A new layout object calculation (like "Hide When") called "Is Disabled When"

That's just one (my) personal take on how this could be implemented in a way that blends in fairly well with the current way FMP works. Far from thinking that it could never happen, I am actually hopeful that some day it might.



This may just be my approach, but a view window and an edit layout.

The difference between visible but not actionable and not visible at all.