We’ve had a couple of challenging behaviours with FileMaker recently that I thought some may find of interest.
On an existing system still running in FileMaker 15, we experienced the Calibri problems reported here - FileMaker Community (English) (‘Calibri + unrecognizable character breaks FileMaker PDF Engine’).
It is very weird having the same field repeated on a layout, within the same context but one using the Calibri font and the other Verdana. An extra trailing character can be viewed within Verdana, but not within Calibri. Our problem has only just occurred on a report generated for an action list for a single user, hence we’ve spent some time understanding the problem until establishing the problem confirmed by the above link. The sad thing is that this was acknowledged 2-years ago and is still a problem from v15 (at least) through to v18 and appears to being caused by a null character (code = 0).
Most text displayed these days is controlled by hidden feature rich code (try replacing the .docx on a Word file with .zip in Windows and extract it to find out what is behind each icon displayed) and we believe the downward facing caret beside emails, telephone number, links, etc. is a player in this. We certainly won’t be allowing Calibri to be used again on a report and will be adding an OnObjectSave script trigger on fields typically being pasted into to remove these characters.
Secondly, we have another system running in FMPA v17 where we export a Word file from a container field, it is automatically converted (via a 3rd party system) to a PDF and reimported into another container field in the same record. We were trouble shooting some slow PDF creation (finally traced to network problems, not our system) and were introducing a scripted pause for varying seconds to check the Word file had been exported and the PDF file had been created before reimporting. However, although the script completed and the PDF imported, it also opened automatically on each user’s PC, which was a change of behaviour.
Replacing the pause by a loop that escaped after a specified count to replicate the same functionality did not open the PDF file, which is what we wanted.
We still cannot work out why a script that exports field contents, pauses before importing a file from the same location would then open the contents of the container field. We left the loop in place and all worked fine.