4 Replies Latest reply on Apr 21, 2017 12:59 AM by Agnès

    FmDynamix, cfCall() and #load()




      I am pleased to present the FmDynamix project, including cfCall() and #load(), my 2 new custom functions.


      FmDynamix is a project that currently includes 2 modules but will probably be expanded.

      The aim is to maximize reusability by providing a modular dose.


You have the presentation file here : fmx_FmDynamix_Presentation.fmp12

      And you will find the explanations here

      after seeing, if then you want to participate in the experiment, you can share with other users your Custom Functions.


      The first module, relates to custom functions, and makes it possible, to simplify, to call a custom function without being stored in the file, the number of functions that can be called being unlimited, They are recursive or not.


      Do not hesitate, interest in you, I think ( I hope ) there are.

      Do not hesitate to use the online files, create and share functions.

      Do not hesitate to tell me the bugs or errors or improvements you think.

      For me, it is obvious. Apart from sharing calculations, I want to see the behavior of cfCall() & #load() with a max of type of function, you will well write me one day a function that perhaps break the thing !


I hope that this "modularity" will please you!

      Thank you






        • 1. Re: FmDynamix, cfCall() and #load()
          Benjamin Fehr

          A word about your DateRange Custom Function:

          I have built a Relationship with DateRange CF to avoid comparable operators ( < > ≥ ≤ ).

          I guess it was HOnzaKoudelka who claimed that comparable operators AND Cartasians ( operator 'X') are performance killers.


          What was

          TableA::Start ≤ TableB::Date

          TableA::End ≥ TableB::Date



          TableA::f_DateRange = TableB::Date


          In some rare cases, specially with PC, the TO would break since with FM Field of type 'Date', there is no control about wether the value is stored as




          or anything else.


          I guess we would need this feature:

          Consistent Format of how FM writes Date-Values internally

          • 2. Re: FmDynamix, cfCall() and #load()

            Cartesian relationship itself is not a peerformance killer, it evaluates instantly because there's nothing to compare.

            For the purpose of consistent date usage - every date is actually stored as number internally. It just also stores the format in which the date was entered by the user. It's up to you as a developer how you decide to display it or convert to a string.

            For relationship purposes, I suggest you always deal with integer numbers. Those are safest and fastest.

            Just do GetAsNumber(date).

            2 of 2 people found this helpful
            • 3. Re: FmDynamix, cfCall() and #load()



              Performance will depend on calculations and evaluations and the depth of the links.

              I agree, but I think we're moving away from the original topic

              I never use DateRange (), I just put this code in the file, only to show that cfCall() can play recursive or simple custom functions.


              Thanks you to test the file



              • 4. Re: FmDynamix, cfCall() and #load()

                Small reminder for those who want to relax with a bit of calculation and Filemaker !

                The files are always open and nobody managed to break the thing

                Have a good day !