7 Replies Latest reply on Dec 9, 2015 9:56 AM by Extensitech

    Divide a layout in colums

    donhoogkamer

      I currently have one body and a search field positioned on the left side. This field automatically searches the records but I would like to have a list view underneath the search bar showing the found set. The right side of the layout has all the fields that are updated.

       

      This works when I change to list view but as you would expect this messes up my layout. How could I divide the layout into colums and returning the found set on the left side and having my records on the right side updated when one of the records in the found set is clicked?

        • 1. Re: Divide a layout in colums
          Mike_Mitchell

          Don -

           

          What you want is called a "list-detail" view. There are a few different methods for creating one; you can search the forum for previous threads. (One of the more common is to use a portal for the list on a form view layout, just to give you an idea.)

           

          HTH

           

          Mike

          • 2. Re: Divide a layout in colums
            Extensitech

            You also might consider putting the "form" section in the footer of a list layout. You get the "list-detail" very easily that way.

             

            Finds and so forth work just like they would in any other list, so you can leverage what FM does on its own. When you switch records in the list, FM will natively show the active record in the footer.

             

            Essentially no scripting, no self-related portals, etc., but it does split your screen horizontally instead of vertically.

             

            This may be a deal killer for you. I'm personally not sure why, but some developers and users only expect the split to be left/right. If that's the case for you, there are a lot of discussions and examples about that. For example: http://www.modularfilemaker.org/module/masterdetail-2-0/

             

            Having done some consulting work in a past life with Siebel enterprise CRM, where top/bottom was (at the time, at least) a "normal" view, I find it quite comfortable, and I can get a a user used to it in about 20 words or less.

             

            I'm (probably) biased, but where I'm going for "list-detail", I find this split much more flexible. IMHO, wider lists tend to be more meaningful and useful, and having the form able to "stretch" vertically might resize a few objects, but it doesn't make new elements fill in the vertical space. Where I'm wanting the objects in the form (mainly fields) to stretch (with anchoring), left-right is usually my main concern, anyway.

             

            Should you wish to explore this option, I will point out one caveat that you can easily work around. In the footer, the tab order won't take you from one portal row to the next. You can, however, add an object to the end of the portal row, at the end of the tab order, with an onObjectEnter script trigger to take the user to the beginning of the row and then go down a row. (If you go "down" first, you'll trigger the next row's object. Obvious, once you've screwed it up like I have! )

             

            One unanticipated advantage: If you shrink the window vertically, to where the footer won't fit, FM leaves off the footer and just shows you the list. Thus, on the desktop, you can effectively hide the form. The user can, of course, just stretch the window, so it's not a security tool or anything, but it's a nice way to focus the user on the list portion. We use this, for instance, when we want the user to click records to select them.

             

            Siebel example (just to demonstrate that the top/bottom split isn't unprecedented):

             

            0561_01_09.png

             

            FileMaker example (pardon the quick and sloppy privacy blackouts):

             

            Untitled.png

             

            HTH

             

            Chris Cain

            Extensitech

            • 3. Re: Divide a layout in colums
              keywords

              Re: "You also might consider putting the "form" section in the footer of a list layout."

              This is a technique I use in a side by side layout—

              Screen Shot 2015-12-09 at 9.17.01 am.png

              • 4. Re: Divide a layout in colums
                Extensitech

                Could you elaborate? How does it help to have a single-record portal on the right? (I'm sure it does, I just don't understand.) Is this two portals, two TO's, a script trigger on the "global selector"?

                 

                Most of all, how is this

                Re: "You also might consider putting the "form" section in the footer of a list layout."

                ? (The "Re" part, I mean?)

                 

                Sorry, keywords. I feel dense for asking. I'm just not making the connection, and I suspect I'm missing something that should be more obvious to me.

                 

                Chris Cain

                Extensitech

                • 5. Re: Divide a layout in colums
                  keywords

                  Sure.

                  1.     Top left is a global field in which to type. This field has a script trigger so that the field and its matching calc (see below)—and hence the relationship it drives—is updated with every keystroke (the script simply exits the field and then re-enters it).

                  It is used in a relationship to narrow down a list of names. The technique is to couple this field with a matching calc field that appends a z to field contents—if you type chr the calc will be chrz, etc. The relationship is set so that the global field has a ≤ match and the calc field has a ≥ match to the name field. This means that with every character you type, the list of matches reduces in the portal below. (Acknowledgments to Ray Cologon of NightWing for this technique.)

                  2.     The left portal shows the reducing list as described above. The portal row is defined as a button which posts the contact ID from the selected row into a separate global field which drives the relationship used in the right hand portal.

                  3.     This whole panel on the right is a portal with just one row, in which whatever detail fields you require from the related record can be displayed.

                  I use this technique for selecting all kinds of records—contacts, quotes, invoices, job cards, etc. etc.

                  I was wrong about the body part comparison though. In my case I use a Form view with no footer part.

                  • 6. Re: Divide a layout in colums
                    donhoogkamer

                    Thanks for your answers! I am going to try the Master Detail version as it looks like it suits my needs completely :-)

                    • 7. Re: Divide a layout in colums
                      Extensitech

                      Thanks for the clarification. I think I'm caught up now.

                       

                      I guess my point was that, if the left/right orientation isn't critical (I know it is for some, but I personally don't see why), then you can achieve the same thing with a lot less scripting, no extra TO's, etc., in a top/bottom orientation. Along about FM 8, data entry was allowed in the header and footer parts. You couldn't before.

                       

                      I remember seeing that in a DevCon preso (which wasn't at all about that, oddly) and rushing out of the room so I could test it. I abandoned the gymnastics of left/right list/form then, and I haven't looked back. It's way simpler, and the only downside is that for some reason people sometimes have a strong preference for left/right, and I've never really understood why.

                       

                      If I'm working with related data anyway (like in a session model) then it doesn't really make a difference since I need portals anyhow, but if I'm on the layout of the list I'm showing...

                       

                      Incidentally, we use the same form I showed (the one with the privacy blackouts) for selections, in a new window. We rename the window, which triggers the small variations (hide whens for OK/Cancel buttons, script parameters on the row click, etc.) for selection, and we also resize the window to only show the list. No additional "select" layouts, no copying/pasting/repointing. Plus, the user can do finds or add new records on the fly (given that the routine parameters don't disallow it).

                       

                      Untitled.png

                       

                      Just sayin.

                       

                      Chris Cain

                      Extensitech