1 Reply Latest reply on May 10, 2016 11:36 AM by erolst

    Using different layouts of the same record

    BenECAFM

      I'm developing from the Projects starter solution. In my business, we have a number of distinct types of project, such as Visa Applications, University Applications, Housing Search, Business plans, Internal Projects...

      Each involves a specific set of data. For example, if we're doing a visa application, we need to know the client's visa history; If we're doing a property search, we need to know their requirements etc etc.

      I've added a field for 'Project Category' so that I can see the category in list view, and will presumably be able to filter and find from that field. What I want is to create a different layout for each project category, probably by adding a Tab control to the project details layout, with a couple of tabs for each layout type with the relevant fields.

      My questions are:

      1. How can I make a new record request demand a choosing of project type?

      2. How can I make the project always open with the right layout?

      3. I also want an easy way on each project of 'attaching' it to a client. So that the project layout shows it as attached to that client, and so I will be able to put a portal to all open and previous projects on the client's record. Similar to adding a resource to a task, but at the project level, and showing the client somehow separately to the resources working on the project.

       

      Yes, I'm a bit new to FM. These may be either simple questions, or I may be going about it in completely the wrong way, so I'm very open to suggestions.

       

      Thank you folks

        • 1. Re: Using different layouts of the same record
          erolst

          BenECAFM wrote:

          1. How can I make a new record request demand a choosing of project type?

          One thing: script the creation of a new record; another: validate the type field on not IsEmpty (and possibly member of a value list, if you'd encode your allowed types in a value list), and disallow user override.

           

          This means that even if someone creates a record via menu or shortcut, that record will be deleted again (reverted) if no allowed type is provided (validation fails).

           

          Of course, even better would be to not create an invalid record in the first place, so if you have FM Advanced consider creating a custom menu where the New Record functionality is tied to a script (this impacts toolbar button, shortcut, menu command … ) that prompts for a type before creating that new record.

           

          BenECAFM wrote:

          2. How can I make the project always open with the right layout?

          Possibly by not creating different layouts at all. You can use the Hide if feature to good effect to hide entire groups of fields and objects if, say, Project::type ≠ theCorrectType.

           

          Another would be to use the Project table merely as a “front-end” that has only the attributes (fields) common to all projects, and implement the different attributes in another table. This way you would only see the correct attributes (related records) because you created them, provided you have a way to constrain the attribute selection to the correct types.

           

          That may be a bit advanced, though, so if you do create one layout per type, the simplest way is to use a consistent naming scheme. If your layouts are named, say, Layout_Visa, Layout_Property etc., all you need is a script with the step

           

          Go to Layout [ by calculation: Layout_" & Project::type ]

           

          and attach that to an OnRecordLoad script trigger.

           

          BenECAFM wrote:

          3. I also want an easy way on each project of 'attaching' it to a client.

          This simply means: in the Project table, create a foreign key field for the client and write their ID into it. You could also create the client and script the creation of a new project of type <prompt for type> for client <id of current client> – another way to assure that every project has the basic ingredients of client and type.