Pasting Layout Objects should write errors to import.log

Idea created by mrwatson-gbs on Feb 2, 2016
    • gham
    • cristoslc
    • Benjamin Fehr
    • Johan Hedman
    • mrwatson-gbs
    • robertnaud
    • CamelCase_data
    • Menno



    Layouting is one of the most common but error-prone activities in FileMaker database development. This is because


    1. Everybody does layouting. (You can have a database without custom functions or scripts, but hardly ever have a database without a layout)
    2. Because of the lack of layout-in-layout functionality, copy + pasting in & between layouts is a fundamental, daily developer activity.
    3. There is a lot to go wrong: ALL aspects of the database are referenced from layout objects: TOs, fields, value lists, scripts, layouts, custom functions, external files, ...
    4. Layout objects tend to be more complex and deeply structured than other FileMaker structures and have more ‘hidden corners’ where things can unobtrusively get broken, or in other words...
    5. It is relatively difficult to find all the errors in layouts than, say in custom functions.


    … but it is nonetheless one of the only areas where FileMaker Pro writes NO information to the import.log file at all, leaving developers stranded with their errors.


    Note: While many developers are unaware of the use and the value of the import.log file, for many others it is a staple of their daily work checking the import.log file to find errors which occur during paste + import operations. This is made easier by the fmLogAnalyser tool, part of the free fmWorkMate toolbox, which particularly helps to see warnings and cancelled operations:

    Bildschirmfoto 2016-02-02 um 10.05.59.png




    • When layout objects are pasted the import.log should be written, as in other copy + paste operations.
    • The content written to the import.log should follow the existing standards of other paste+import operations as closely as possible, e.g.:
      • If the layout is not saved but canceled (reverted), then the import action must be marked as 'Import operations canceled’ as in other areas of the database (e.g. when pasting Custom Functions)
    • It would be helpful if log entries considered to be warnings would start with the word “Warning! ”, so that these are more easily identifiable as such - both by humans reading or tools analyzing the log.


    The following events should be logged as errors (or only as warnings should they occur in a setting that is not currently active, e.g.: a missing value list on a field which does not use value list should only be logged as a warning and not an error):


    • missing table reference (i.e. TO)
    • missing field reference
    • missing value list reference
    • missing external file reference
    • missing script reference
    • any calculation commented out due to an error, including
      • script parameter calculation (on buttons + script triggers)
      • all script step calculations (e.g. Layout by name, etc.)
      • conditional formatting
      • hide calculation
      • tooltip
      • placeholder text
      • accessibility info
      • calculated button names
      • popover title
      • chart calculations
      • webvieler URL
      • portal filter
      • tab names
    • missing font
    • unknown object type (from future versions of FileMaker)
    • missing style
    • illegal layouting combinations, e.g.:
      • portal in portal
      • etc.


    The following events should be logged as warnings:


    • An object name that is renamed due to clash with existing object name
    • An automatically created external file reference


    The treatment of the following events to be discussed:


    • missing placeholder reference with the following format <<whatever>>    // it could be argued that this is not a placeholder, but I think 99.9%+ of all cases it represents a broken field reference, and in less than 1‰ of the cases this may be a false positive. => in my opinion in it makes sense to highlight this as an error in the log
    • missing placeholder reference with the following format <<table-name::field-name>>    // This I think should definitely be logged as an error
    • If it can be identified that the target layout is for an iOS device, then it could also be useful to flag up incompatible objects


    Imagine if ALL those errors were immediately findable via the import.log! Wow!


    If I have missed anything, please let me know in the comments and I will add it to the list!




    • Copy and paste will just work better than ever
    • Untold errors will be found!
    • VASTLY Increased quality of developing - and deployed - solutions
    • Reduced maintenance, due to less errors in deployed solutions.
    • Helps Improve UX of Layouting with Themes and Styles
    • FAR greater productivity (laborious error hunting becomes snappy error zapping)!
    • Beautiful, aesthetically appealing and above all error free layouts - the face of your database and the marketing front of your business
    • Happy developers, happy end users, happy FMI


    Use Cases


    • Layouting, every day in every way




    Above all, I can well imagine that implementing this is a piece of cake! All of the structures are in place (writing to the log) - it simply requires calls to the logging routines to be built into the code at each point where an error occurs.


    Come on everybody, you know you want it! Vote it up!

    Come on FMI, this is an easy one to win points on!




    Happy be!