4 Replies Latest reply on May 12, 2011 4:17 PM by aammondd

    Need some development approach help

    aammondd

      Title

      Need some development approach help

      Post

      I have worked with FMP for a while now and have some pretty hefty script trigger features that Ive developed in testing.

      What Im after is a suggestion on development techniques for how to ensure that all the trigger settings get retained when I place a field on a layout

      Would it be prudent to have a development pallet like layout to copy and past fields from or is there a  better way?

      Im using a number of records that consist of only global fields to control a number of things and was wondering what challenges I might run into if I used these records as my primary layout record?

      Im currently using FMP 11 Advanced on Windows and have a few applications I plan to design that will have common features. Im guess Im looking for some tips on setting up my development platform with the "custom toys" I have been able  to build.

      Because Filemaker is generally so free form I havent seen any "tool" out there that does quite what Im looking for. Im not sure I really want to spend a ton of time building a "development solution" but Im sure there is some middle ground to be had to take advantage of common development features. 

        • 1. Re: Need some development approach help
          philmodjunk

          Would it be prudent to have a development pallet like layout to copy and past fields from or is there a  better way?

          That's a very good way to do this. This can also help you standardize field height, text format, etc.

          Im using a number of records that consist of only global fields to control a number of things and was wondering what challenges I might run into if I used these records as my primary layout record?

          How's that again? If the fields are all global, then every record in the table will display the same data on every record. You don't need any records in a table if all the fields have global storage specified.

          • 2. Re: Need some development approach help
            aammondd

            I tend  to have a number of relationships to values in these "global tables" I also use them for work records to standardize the data input stored elsewhere in the database/solution (such as odbc linked tables) they let me do quite a number of things. I tend to use  them alot to store environment and user data that enable a number of custom security features ( these features are extensions of the native security that I am able to pass along to users to administrate without opening up Filemaker's native security.)

             

             

            • 3. Re: Need some development approach help
              philmodjunk

              Yes, but you said "I'm using a number of records". Multiple records of the same table where all fields are global are all going to show exactly the same data all the time.

              I do find it useful to put all global fields that aren't used as keys in a relationship in a single table. It makes them easier to keep track of and they can still be accessed from any layout and from any script in my solution. (no relationship between tables is required to access global data as long as it is defined in a table of the same file.)

              • 4. Re: Need some development approach help
                aammondd

                Im used to the terminology of a record being the equivelent of a table. I should have said tables. I can see the misunderstanding.

                A FM record would be a row. Ill try to remeber that its a confusing terminology difference