1. How do I try out FileMaker Pro?
You have a couple of ways to go about this. One is to download the trial version from Apple's own Claris web site. This is a fully working version (now that the Runtime feature is gone because Apple thinks everyone will move to the M1/M1X AMD-based Apple Silicon Mac computers and run FileMaker Go on desktop and iOS devices) but time-limited to 45 days. Alternatively, and knowing the improvements are not significant in the FileMaker Pro arena, you can purchase cheaply a perpetual license version of an older FileMaker Pro app from eBay. Nowadays, you can easily spend less than US$50 on FileMaker Pro 18 (at the time FileMaker Pro 19 came out). The same is true of FileMaker Server 18.
2. Is it true that Apple wants to remove the Runtime feature of FileMaker Pro?
Yes, and it has. As sad as this sounds, it is true. As of FileMaker Pro 19 in May 2020, creating a Runtime app for Mac and PC is no longer an option. And even if FileMaker Go runs on a desktop, Windows users will have nothing other than to pay for a full copy of FileMaker Pro. No wonder so many PC administrators hate FileMaker Pro. And as one person advertising for help to convert a FileMaker Pro database solution:
"I have a Filemaker database and would like to have it operational as a MS access. This should allow me better access to newer programs and the increasing cost of FileMaker."
The removal of the Runtime feature put off side a lot of FileMaker developers and ordinary people who have simpler needs for creating a database. For example, Thorsten Wolfgang Giessegi, a FileMaker developer from Germany said on 21 July 2020:
"As a Mac user for more than 30 years now, I'm not happy with the direction Apple goes now and as a FileMaker developer, Runtime Solutions take a big part of my business, I'm very upset with the license policy of FileMaker. If there is no cheap client available anymore, selling FileMaker solutions for small businesses or individuals would become nearly impossible."
The technical term used by developers for this situation is called "deprecation". It simply means that a reason has allegedly been found by a developer for removing a feature or function. The reasons are varied, but it is mainly because:
- It is too hard to support a certain feature or function (unlikely if people see the value in maintaining the feature or function).
- Hardly anyone else is using the feature or function (because technology has evolved to something else that is suppose to be better).
- To reduce competition from other developers using the software (because it is considered by the developer of the product too powerful in what it can do).
Richard Carlton, CEO of RC Consulting, has raised another possibility: the issue of profitability. As Carlton mentioned in his video on Calendar Improvements in FMSP 2020 on 13 July 2020:
"Claris deprecates very few things in reality. They deprecate some image formats like EPS and some other formats like that. They deprecated the Runtime, which has people squealing. Ah well, I am getting on my high horse about that. I am really happy to criticize Claris when appropriate, but that one? Basically [the original] Claris [Corporation before it was bought out by Apple] came up with a Runtime....I have a big concept in business or even working with my team that it has to be a win-win conversation. If I'm getting something out of the deal, they need to be getting something out of the deal and both parties are winning. When you buy FileMaker for $99 a year or whatever you are doing and then you make a Runtime and you give the product away to a bunch of people, Claris isn't getting any value from that. And people say, "Ah well, they could upgrade the full version". Very few people who get the Runtime [will] upgrade [to] the full version of FileMaker, So Claris (i.e., Apple) determined, and they said this over for the last 15 years (because Runtimes have been around since FileMaker 3, which is 95, so 25 years [it] has been out there), that they were not making money off of it. And so, if you build a business model upon where you make the money and the person supplying some of the parts doesn't make anything, then eventually [everyone is] going to go out of business.... And so, the fact that they let the Runtime survive so long was a testament to them kind of being nice. I think they could have solved that a couple of different ways, solving multiple problems simultaneously, but yeah....I'm not on their Christmas card list down there [at Claris] so they do what they do and we just get to watch from the sidelines. So anyway, nothing has been deprecated other than the Runtime [and[ some image formats. There's no fundamental capabilities or script steps that have been removed."
Well, actually the Runtime feature is a fundamental capability for FileMaker developers serving their clients or selling to customers. And if Ronnie Rios, a senior consulting engineer at Claris, is correct in his video on FileMaker 19 Add-Ons when he stated the aim of Claris/Apple was to:
"We make powerful technologies available to everyone."
then it should be obvious how Runtimes should be an important strategy in getting people to be, at the very least, introduced and using FileMaker Pro. However, this is not the case. Apple has another reason.
This brings us back to the profitability question. In other words, is it the lack of profits that has led this behemoth company to make this unfortunate decision to remove the Runtime feature? Well, let us put it this way: Apple is not exactly struggling to make a profit. It could choose to retain the Runtime feature in FileMaker Pro (especially on the Windows machine) even though it has been able to sell in the past a large number of FileMaker Pro apps (even with the higher priced FileMaker Pro Advanced) for many years. With every new release. FileMaker, Inc. as the subsidiary company of Apple was once called, and now renamed Claris, presumably because it would give the impression to customers that this was the original Claris Corporation that created high-quality, feature-rich, and very stable software products has always been more than sustainable. It made significant profits with each upgrade. Yet, for some reason, the profits were not sufficient. Thinking that perhaps sales of FileMaker Pro might go through the roof at Apple headquarters, the company decided to remove the Runtime feature and force people to buy FileMaker Pro. Does this mean Apple is a megalomaniac that does not know what reasonable profits is all about? Or is this just a normal thing for a shareholder company to do?
Or was there a third-party product from a FileMaker developer that was the impetus for Apple to make the decision to dumb down its FileMaker Pro product, including removal of the Runtime feature?
Well, it makes no sense to think of it as a profitability issue when you realise there is a simple way to create a "Win-Win" situation for everyone. All Apple had to do was disable in the Runtime app new and important product features introduced in the upgrades. Let FileMaker developers showcase the new features for customers to run in FileMaker Pro, or else stay with the Runtime option. Just make the features look so good and achieve important tasks people look for and you can be sure a large percentage of customers will want to buy FileMaker Pro. That's all there is to it. Yet, remarkably, Apple was unable to come up with this solution. And on reflection, it is obvious that there could not be any way for Apple not to have noticed it. A reasonable person would have realised that it would have been fine to continue providing the Runtime feature in FileMaker Pro and followed the above approach and Apple would be making a bigger profit today if for any reason the profits were not substantial enough from selling FileMaker Pro and FileMaker Pro Advanced in previous years (well, let us put it this way, FileMaker, Inc., the old name for Claris, Inc,, was not indicating it was financially struggling and nearly on the verge of selling up and disbanding the organisation). Instead Apple has chosen not to do it for another reason.
This leaves us with the only viable explanation for removing the Runtime feature: it was to stop FileMaker developers from creating products that could compete and do a better job than Apple's own free iOS/macOS apps. Even when the Apple Silicon chips arrive to enable iOS apps, such as FileMaker Go, to run on macOS, what users will get is an inferior replacement of the Runtime app with no ability to run plug-ins. Plug-ins have the power to meet many shortfalls in the features available in FileMaker databases, and this is one thing Apple will refuse to provide in the next version of FileMaker Go. It is all done because deeper down there is a reason why Apple wants people to use its apps, not FileMaker apps from third-party developers. It is a question of learning about its customers, developing profiles, and seeing what they are doing and the apps being used through the Push technology, as well as to show anti-competitive behaviour to third-party developers who might interfere with Apple's aims. Among the various ways the company will do this include reducing the price and eventually provide certain apps for free, as well as to use its marketing strength to promote and create the perception of Apple products being better. Furthermore, Apple will try to convince people that simpler is better to the point where the company creates very pretty-looking but significantly dumb-down Apple products. So long as this perception is maintained and the price is very low-cost or free, Apple was hoping to stop other developers from competing and/or making a profit in specific areas that Apple wants to have control over, as well as help the company make a bigger profit for itself in selling the more commercial variety of Apple products like FileMaker Pro to customers. It is not about giving customers the best software it can with all the features people look for. The company's profit mentality and determination to prevent one alternative solution that could have easily avoided the loss of the Runtime feature and still give the shareholder company the profit it wanted. It has to be because of anti-competitive behaviour.
That was why Apple introduced the Bento product some years ago (probably built with FileMaker Pro but with extra features not available in FileMaker Pro and so it required the original source code of Bento to be compiled using Xcode to give Apple the extra competitive edge over FileMaker developers in the hope that certain people making database solutions would not pursue their products) and its pricing designed to undermine that of SUNRISE Contacts by exactly half. Since that did not work and Apple decided to end the Bento product to avoid being seen as giving itself a greater advantage over other competitors because it would not allow the same functions and features to be provided in FileMaker Pro, the only solution was to end the Runtime feature. This was Apple's way of avoiding healthy competition among software developers using Apple products.
Apple does not want FileMaker developers to create more flexible, secure and feature-rich apps. Apple has a reason to provide Mac users with over-simplified solutions of its own as we see on Mac and iOS devices. Unfortunately for the company, SUNRISE Contacts was an example of the type of software that could have forced Apple to be more competitive or else lose customers to the FileMaker community. So to handle this situation, Apple knew SUNRISE Contacts relied on the Runtime feature to create a self-contained app. It was better for the company to use its position of power and control of the FileMaker Pro product to effectively stop third-party competitors from competing with Apple. Instead it wants developers to become "sales people" in selling the Apple product, but not to improve and provide better solutions to Apple's own free offerings. FileMaker databases and the Runtime feature were known to the company's management team to pose too much of a problem when it came to its free contacts.app on macOS and iOS. It gave people choice. and it can also potentially affect Apple's profits if the software can challenge the aims of Apple in pushing people towards a certain pay-as-you-go model of service delivery as Apple prefers. Apple wants people to use its apps (one of the reasons why Apple provides free apps with the OS), or else force everyone to go online and on the Cloud and pay for nearly all the services where it can identify everyone as they achieve some goal (in most cases, it is probably to make a profit). And to make sure of it, any means of having an advantage over FileMaker developers would be highly advantageous for the company. Try to stop others from competing against Apple. Removing the Runtime feature is one way to achieve this anti-competitive aim. Somehow Apple is hoping developers will see the advantage of paying Apple to join its elite Apple/FileMaker Developer's club, and users and businesses to join the Cloud-based club called Claris Connect (for a regular fee, of course) and turn them into advocates and eventually sales people, but not to compete with Apple through better products. There will be some discounts as a reward for those FileMaker developers who do the right thing by Apple. Mainly to provide cheaper FileMaker Pro licenses to sell to their customers. But FileMaker database solutions can never be provided for free or very low-cost. It would cost more for FileMaker developers to sell their database solutions as they must include the price of FileMaker Pro app itself.
But there are long term consequences of following this approach, as it will become clear in a few years time. Once the software is out there in reasonable numbers, FileMaker developers will become a dying breed. As Apple simplifies the software and makes it web-based (i.e., "dumbs-down" and make it cost everyone a regular subscription fee to use), FileMaker developers would no longer be needed by the company. They will join everyone else made unemployed by AI technology. They will have to be more innovative and find alternative jobs to pay their way through life.
Apple would rather see FileMaker developers sell more FileMaker Pro apps and force everyone to buy FileMaker Pro just for the privilege of accessing the database files. And eventually Apple wants everyone to be on the Cloud (helped along by Claris Connect as a separate API service). If this isn't enough incentive, in two to three years from now, a new processor with a reduced instructions set will likely see many current Intel-based apps no longer work. Bad for Runtime apps. But great if you are an app developer wanting to get everyone to use online-apps only, seeing what everyone is doing, racking in the profits, and take advantage of the work other people do online. In that way, people will be asked to pay for endless subscriptions and, at the same time people can be monitored, right down to all the tools being used, develop a profile of people and their businesses, gather some business confidential information and ideas that developers can use or "steal" for their own commercial interests, and find innovative ways to encourage people to pay more for extra features that may be useful in the future. Every feature must be used regularly by enough people, and all have to be done online for some reason, and designed to maximise Apple's own profits on a constant basis as if it is struggling to make a profit. Not likely looking at previous releases of the FileMaker product. At the moment, Apple thinks removing the Runtime feature will not affect sales as it thinks very few people will use it. If that was true, why disable Runtime in the trial versions of previous FileMaker Pro versions? Too powerful to let people try it out? Or was it simply the fact that there were people using the Runtime feature and Apple did not want to give away this ability in a trial version?
As can be seen, the word "deprecation" does not necessarily mean a function or feature has been, or will be removed. Sure, there is a strong indication that a function or feature is likely to be removed, but it need not necessarily be the case that it will. Various factors will determine how likely a feature or function will disappear from an app. For Apple, the term may be nothing more than a cost-saving decision to dumb down software and reduce the costs and time to support extra features. But then again, you would expect the company to be listening to users to see what they want. If people say they don't want to lose certain features, a sensible software developer would avoid removing them. Indeed, for other developers, it is usually a way of determining the reaction of users in hearing about the proposed removal of a feature. Should there be enough complaints from the users, the "deprecation" status of a feature is always dropped. For Apple, this is not the case. It had plans to remove the feature for a long time. It was not the lack of users using the Runtime feature, or whether people would complain about its loss. Apple knew the feature is too popular and useful to a lot of people. Far from it. Nor was it a profitability issue. Apple was constant making healthy profits from the sale of FileMaker Pro and the Advanced version for many years. The only reason Apple had to remove it irrespective of what users and developers want is because the Runtime option was giving some developers the ability to compete with Apple's own free apps or paying Cloud-based apps with alternative and more privacy-protected solutions and features that Apple was not prepare to provide to Mac users in its own apps. Apple did not want the extra competition, so it felt entitled to remove the feature thinking this will avoid the extra competition and so get additional profits while benefiting from constant monitoring and identifying of people, especially when everyone goes online and the FileMaker Pro app only works as a web-only app.
It was not about understanding the needs of the users and developers. Apple was not interested in listening to users on what they want to see in the Apple products. Rather, it did everything it could to hide this "advanced" (or "pro") Runtime feature. Right down to hiding a checkbox in the Preferences dialog to make the Runtime feature visible in the menu. Apple really wanted to push FileMaker Pro to no longer have this advanced feature or at least not be visible to new users. It was not a case of insufficient users using the Runtime feature. We know plenty of people used the feature. At the end of the day, it was a determined decision by the company to remove the feature by any means.
To force further changes on users, FileMaker Pro 19 no longer supports Windows 7 even though there are plenty of PC users out there who are happy to use Windows XP and 7. It is not a numbers game for Apple of how many users are on a version of an OS. For Microsoft, it is a numbers game. Microsoft has not moved on from Windows 10 despite making sure it can run nearly all legacy software on it. The company had hoped this compatibility aspect would encourage users to upgrade, but it hasn't.,For most users, they are happy with Windows XP and 7. Windows 8 had major problems, and Windows tried to improve on the mistakes. Windows 10 is much better but it is a monstrosity to install with little or no added benefits to Windows 7 other than to fill up more disk space. So now, Microsoft is in a quandary on what to do next. Should the company release Windows 11 or not? The decision so far is to stop upgrading the OS. But Apple is different. With a younger market of Mac users who think anything new equates to being better and a must-have feature (so they can brag to their Windows friends about how good the Mac is), they are more likely to adopt almost any kind of changes (if they think it is sufficiently different and better in their minds), even if it seems very minor or cosmetic. And Apple knows this. The company takes advantage of the situation to get people to upgrade who seem silly enough to spend money buying new Macs and upgrading third-party software on a regular basis to get things working again. Now that Apple has some experience in how to do this and brought it down to a fine art, Apple is trying to help Microsoft to force people to upgrade the OS, as well as itself and to capitalise on these continuous "apparent improvements" for the sake of making high profits in selling the latest Mac to run the latest OS, FileMaker Pro to open and use database files, and any other software. Now FileMaker Pro 19 will not work on Windows 7. Only Windows 10. How interesting? It is the endless treadmill of forcing users to change and pay if they want something to work. And even then, Apple is dictating how people should do things, and make a profit along the way in doing so if users are silly enough to accept the changes.
It is amazing. All this effort to remove a key feature of FileMaker and considered unique to database development at its price point (even if one had to pay an extra $300 for the privilege, and far less than Microsoft's own Runtime solution for Microsoft Access) despite the fact that Apple offers the free Xcode for developers to create any software they like. Developers can make a CRM if they want with Xcode and sell it. No doubt Apple hates the idea. So the only thing Apple can do to control this potential extra competition should some developers decide to go in that direction is to apply the regular upgrades of the OS in order to make slightly old software not work again, and so forcing developers to regularly pay their annual developer's subscription to receive the code-signing certificate and update their software with the latest Xcode just to make their software work again, and all the while Apple wants to claim the new OS is an improvement and necessary for all Mac users (cough!). Somehow FileMaker Pro cannot be allowed to do the same. It does not matter if most people describe it as foremost a software development tool with a database feature added on, especially for the Advanced app version. This is not how Apple wants to see it. Rather, the development of FileMaker databases should serve a more dumb-down purpose of simply storing data, allowing the data to be found, and having it used in-house together with a pretty interface should people want to go that far with it. There is no point as far as Apple is concerned in having a self-contained and running app that could be used and sold to "external customers". FileMaker Pro is not Xcode and Apple wants to make sure of it. Furthermore, Apple will not offer an alternative to the Runtime option in FileMaker Pro, such as a tool to migrate and compile FileMaker databases into Xcode to work as self-contained apps. FileMaker developers are required to find alternative third-party solutions for creating a Runtime solution if one exists.
So where are we at with FileMaker Pro?
At the moment FileMaker Pro 16, 17 and 18 can generate Runtime apps to run in current OS versions. This means SUNRISE Contacts will continue to run for at least the next 5 years on a Mac, and twice that on Windows. We will continue to offer this feature while there are enough interest by users in having a Runtime solution.
After that time, you can create a virtual disk made with VMWare Fusion, Parallels Desktop, or VirtualBox to run an older OS (Windows 7 to 10, OS X/macOS 10.10 to 10.14, or Linux) version. SUNRISE Contacts will run happily on this system, together with FileMaker Pro if you choose to have this tool as well. You can also use Boot Camp. However, when the new microprocessors arrive in approximately 2 to 3 years from now, your better option will be in the use of a virtual disk. In terms of performance, this should not be a problem thanks to the speed of Solid State Drives (SSDs) these days. Of course, if you do happen to have the latest FileMaker Pro available on your desktop (and before the day when Apple chooses to make everything web-based), you will have no trouble running SUNRISE Contacts. However, if you want a self-contained and running app that does not require FileMaker Pro, FileMaker Server/Cloud, or be locked into a particular OS to use it, there is a movement online to read/convert FileMaker files into a suitable programming language. The benefits of this approach is that the files can be compiled into compact and faster running self-contained apps with greater compatibility on a wider range of platforms for you to run the app. At the moment, the ability to convert FileMaker files is about 90 per cent there as of May 2020. Over the next five years, this will increase to at least 99 percent. Already there is an effort to completely reverse engineer the FileMaker "fmp12" file format. And once that is complete, conversion will be 100 per cent effective. In fact, FileMaker developers can continue to create FileMaker apps in FileMaker Pro until such time as Apple chooses to push its product as a web-only app. After that time, developers will have a permanent Runtime solution and one that is more flexible than Apple's offering. It will be the solution to the Runtime loss and one that can run more flexibly on Linux and Android as well as Mac, Windows and iOS.
The only good thing to come out of this news is that SUNRISE Contacts with its Runtime app will continue to work with all Windows 7 to 10 and the next couple of macOS versions. Later, you will have a choice of running it through an emulation program on a virtual disk, or the fact that an alternative solution exists to enable a standalone app to be created and not be influenced by the decisions of Apple in stopping it. Or else Apple will inadvertently allow FileMaker Go to run on macOS on the new Apple Silicon Macs to behave like a Runtime solution, since FileMaker Go is free. But for how long? If there is any substance to this "profitability" claim as the reason to lose the Runtime feature, then we should expect Apple to eventually decide to put a price tag on FileMaker Go in the next few years.
To learn more about some of Apple's anti-competitive practices to prevent SUNRISE Contacts (and other similar solutions) from competing with Apple's own similar OS X apps, click here.
If you need the final and latest Runtime app to run for as long as possible, download Mac or Windows file and drag-n-drop the FMP12 database files into this new SUNRISE folder. These are the final stable and most compatible apps you can get today. For iOS, use the free FileMaker Go app (which is not yet obsolete). For Android, Linux and other users, wait for a compiled version of SUNRISE Contacts in the near future, or you can use WebDirect on FileMaker Server if you want to financially support Apple in its aims.
As a side-note, a number of Not-For-Profit organisations that have relied on FileMaker Runtime solutions to lower licensing costs are being forced to move to another platform as of May 2020 using one of the competitors' alternative "database solution" products, most notably SalesForce. It is considered the lesser of two financial evils when compared to the increasingly higher costs of Apple's FileMaker platform. This is especially true when we are talking about FileMaker Pro and Server in the numbers required to be effective and useful to an organisation and in order to meet the new licensing requirements. Unless CEOs are the Elon Musk's of the world with money to spend, most ordinary organisations will no longer see the FileMaker platform as a cost-effective strategy. We can only re-iterate our earlier question: "Why remove the Runtime feature?" There is certainly nothing particularly innovative about this decision from Apple to do away with the feature. Clearly there were people out there who found the feature useful and, in many cases, essential. Instead we have a spiteful company that is too heavily motivated by excessive profits (as you can expect from a shareholder company that does not understand sustainable and sensible profits, only excessive profits to keep shareholders happy) and wants to be anti-competitive where it can to protect its own interests.
3. My FileMaker Pro 18 Runtime app crashes on launch. Why?
Funny that should appear at this time (just before the release of FileMaker Pro 19 that comes without the Runtime feature). As part of the effort by Apple to discourage people to use the deprecated the Runtime feature, the company has conveniently put in a bug of its own (with absolutely no testing performed if it was accidental). It concerns whether the runtime app is allowed to launch on the latest macOS High Sierra or higher versions. Fortunately there is a solution. If the generated runtime app from FileMaker Pro 18 is not launching on your Mac because it shows the message, "EXC_CRASH (Code Signature Invalid)" in the crash report, you need to:
- Show Package Contents of the Runtime app itself.
- Inside is a folder called "_CodeSignature". Delete it.
- Close the folder.
Launching the Runtime app on a Mac should now work. This is the only difference to be found (apart from the general FileMaker engine updates, which is extremely minor) when compared to older Runtime apps and the reason why those older apps can still run on macOS High Sierra or higher.
4. Why is FileMaker Pro 16.0.6 is now generating damaged Runtime apps on a Mac?
Did you update from 16.0.5 to 16.0.6(.666)? The final update to FileMaker Pro 16 (version 188.8.131.520) released in June 2020 and with its infamous 666 incorporated into the version number now creates incomplete / damaged Runtime apps to prevent people from using this feature (or force users to upgrade). It is imperative that you maintain a copy of the 16.0.5 update or FileMaker Pro app with version 16.0.5. Unless you already have the Runtime created and working for you in your solutions, you will have to downgrade.
We will investigate the changes made to the Runtime app...
The Runtime apps for the Mac have been analysed. The critical change that stops the Runtime from running is in Info.plist. Use Get Info on the app and choose Show Package Contents to find this file. Here are the differences between 16.0.5 (left) and 16.0.6 (right).
As you can see, some information has been lost at the end of the text file in 16.0.6 compared to 16.0.5.
If you have created a Runtime app in version 16.0.6, you can move the latest package contents except Info.plist to your 16.0.5 Runtime app version containing the same database files and having the same date/name identifier. It will work.
Have you already updated to 184.108.40.2060 by mistake and don't have a way to go back with the right updater and/or installer? You can download FileMaker Pro Advanced 220.127.116.113 (use your serial number to install) and apply the FMPA 18.104.22.1680 Updater.
Now testing the PC side....
Runtime apps generated on Windows by FileMaker Pro 16 appear to be working fine for version 22.214.171.1240. This final update should be fine for PC use.
5. How do I import SVG images into FileMaker Pro?
A good choice of a graphic file format. SVG images are resolution-independent and infinitely sharp images. You can scale them up to any size on a layout and it will look sharp. However, the only way to import SVG images into FileMaker are as follows:
- In Layout Mode, choose Insert-->Button from the menu.
- There is a button with a + sign. Click on it.
- A dialog box appears to let you select the SVG image.
- Adjust size according with the slider.
But as you will discover, Apple/Claris has not provided a field box to enter a custom image size in pixels to any amount. All SVG images will be kept to a maximum of 128px. If the company is so eager to promote innovation, how about putting in a field box to control image size properly?
There is one more thing you have to do prior to importing SVG images for them to benefit for FileMaker design features:
- Open the SVG file in a text editor.
- Do a search for those text lines that start with "style=" and contains within the quotation marks the words "fill" and "stroke". After the ending "greater than" symbol, put a space character and type class="fm_fill". What follows after this should be the data to draw the shape of the image starting with d=". The purpose of adding this class information is to permit button icon color to be applied to the image by FileMaker.
- Repeat step 2 for all other lines with this fill and stroke information for each shape making up the image.
Now you can import the SVG image into FileMaker Pro.
NOTE: Not all SVG files will show a fill and/or stroke information, so knowing where to put the FileMaker class information can be tricky. You either have to import into Adobe Illustrator and re-export to get that information visible for you to add the FileMaker requirement (and with the added metadata and other crap that comes with Adobe generated files, or wait for Apple/Claris to be more innovative in getting this whole process streamlined and working in one go within FileMaker Pro. It is time to have this fixed.
6. I have FileMaker Pro. Do you have advice on how to organise my FileMaker solution during development?
You have probably seen various standards of naming fields, tables, scripts, layouts and so on and other standards, such as this one from RCC. What is in common with all such standards is a means of organising your solutions in a way that not only help you to understand what you did in 6 months time, but anyone else who may be required to look at your solutions (sounds likely? It is only when you work for a team of developers will you understand the importance of keeping your app well-organised.
The way RCC does it is mainly to get a lot of the beginners and intermediate FileMaker developers on the same page with each other, and with the assumption that FileMaker solutions may get dissected and improved by other developers. It is about helping everyone to understand what has been done in a solution. However, despite the good intentions of the people at RCC and anyone else who has developed this organizing convention, there are drawbacks. For example, the idea of putting numbers against layouts such as L10, L11, L12, etc might help if you are talking to another developer a million miles away about a particular layout (because they might be required to work on the layout), but it makes no sense in the scripting environment using a simplified and powerful script to handle multiple layouts in the simplest way. As an example, some auto update scripts may require running for a selected range of layouts (e.g., card layouts versus standard layouts). Otherwise you will end up writing in your script a complicated IF Get(LayoutName)="L10..." OR IF Get(LayoutName)="L11..." OR and so on THEN DO THIS SCRIPT. Really? This is a PITA.
Some organising is acceptable, and probably necessary if you intend to go back to your solution at a later date.
For example, use folders as a means of organising layouts based on their function and how they are related by the relationships established in the tables underlying the layouts. Also think about the scripts and what they need to do with those layouts. If you like, add at the beginning of the layout name a word like "Layout" or "L" for standard layouts, "Card" or "C" for card layouts, and so on. Don't worry about numbering every single layouts, scripts, and fields to the nth degree, or else you will find your scripts and custom functions will get overly complicated. And if you have to rearrange the layouts in order of priority or importance or realise another layout needs to be associated with a different group of layouts in another folder, it is going to be extra work in renumbering the layout names.
We agree that variables (both global and local) as well as fields should have meaningful names (e.g., Last Name is better than LN). And there should be just the right amount of comments in scripts or in folder names to provide an understand of what each important section of the script or layouts do. But don't write copious amounts of comments every second or third line. This is something that we have seen RCC do, perhaps for the sake of explaining things to FileMaker beginners in a sample file, when the coding and comments could so easily be dramatically simplified. A classic example has to be the application of REST APIs, and the shocking number of $variables used presumably to break things up and explain things (together with lots of comments) when a simple LET statement can prepare the data compactly prior to sending the data off through the SEND AS URL statement and yet still be able to explain the guts of it easily enough).
At the end of the day, you use whatever organising system that works for you. But as your solution grows and with the possibility that other developers might get involved, you should come up with a system that anyone can understand and helps to fully document what you did. And what that system should be will depend on the type of solution, how sophisticated it is, and how you you design your scripts to be simplified to handle many aspects of your solution.
If you need rules to follow, there are really only four basic rules to organising a FileMaker app:
- Keep It Simple S*** (KISS) as the old adage goes still applies to FileMaker apps. If you can think of a simpler and more elegant way of achieving the same task, whether it is on the user interface (through fewer clickable buttons etc.), within the scripts, or even the tables and relationships you form within your database solution, then do it. The simpler something is and makes sense (i.e.becomes intuitive) to you (and for other people), the easier it will be to use the solution and with ruthless efficiency and effectiveness, or to debug later. In fact, in the latter case, it will help you to see the big picture of how the various important parts of the app works with respect to everything else. And it can have another unintended benefit in keeping things simple: it can speed up your solutions (especially while Apple is not able to provide a compiler to convert FileMaker solutions into proper 'machine code' apps, and yes the company has stupidly removed the Runtime feature from FileMaker Pro version 19). It kind of lends into the idea that RCC and Nick Hunter keeps banging on about with users in regards to "Lean Design". Or alternatively, just give FileMaker developerss a compiler to get the speed users are looking for (not likely since Apple has a reason to keep FileMaker Pro where it is).
- Name all your layouts, fields, tables, scripts, custom functions, LET variables and so on in a way that makes sense not just to you but also the average Joe Blow on the street. The test to see how well you have done this is to come back to the solution in 6 months time. Ask yourself, can you pick up from where you left off or look at any other aspect of the app and know exactly what is going on in less than 5 seconds? If you can, brilliant. You have the right organising system in place. If you can't, you have not named everything clear enough and easy enough for you to do your developing work on it.
- Provide the right amount of comments for important sections of your scripts or guts of your custom functions, and essential layout groups, to help you understand what those key sections are doing. Try to use the fewest words to describe it. To test if you have done this right, can you be asked by another developer to find several lines of a scripting code quickly not just by the way you have named the scripts, but also the comments that help you to hone in on that important piece of coding sub-script?
- Finally, use your solution day-in and day-out. Ask yourself every time you perform a task, "Could I have done this easier?" Not only will the bugs emerge to help you wipe them out faster than than a frog with a 7 inch tongue at a fly convention, but you will simplify the solution and number of clicks to achieve your tasks and with an interface that is totally intuitive to a level that will be ridiculously easy for anyone to use (and no need for a Dummy series of instruction books to explain what is going on).