8 Replies Latest reply on Dec 14, 2011 8:59 PM by projay

    Main Menu Question



      Main Menu Question


      When I developed my database I started with a Orders Table. 

      I created a layout "MainMenu" in the orders table...now that things have increase to other tables and layouts...so I am just wondering from you developers viewpoint is that a good idea for me to have the main menu layout in the orders table?   

      Or should I create another table just for my "mainmenu".

      On the main menu I have several different TO's joined to it to provide me different views/lists...for ie "products to order"..."jobs to deliver"...etc.

      Any info would certainly help me in the right direction.  Thanks in advance...Jay.

        • 1. Re: Main Menu Question

          Create a Table for your Navigation.

          Copy and paste the existing Main Menu into a new layout in your Navigation Table

          You might find the "WhitePaper for FMP Novices" useful.


          David Anders
          The Computer Guy, Seattle

          • 2. Re: Main Menu Question

            So I take it that that is the best way to do this....is to make another table for navigation purposes only.


            • 3. Re: Main Menu Question

              Hi Jay,

              You can use any layout as a Main Menu but if you create it on a table with a lot of records, FileMaker needs to download those records to your User when they access the Menu. This can use resources needlessly.

              Most times, people create their Main Menus using their Preferences table (table with always only one record) or, as Dave Anders suggests, they create a navigation table where one table occurrence group can show all of your portal summaries.  It is often-times called a Dashboard.

              • 4. Re: Main Menu Question

                 Thanks Laretta and Dave for the input...looks like another little project for Sunday night.

                Just wondering about the follow set-up...trying to create a dynamic list using TO

                CustomerInfo             CustomerInfoList(TO)
                _kpCustId      X          cCustId
                CustStatus     =          cCustStatus  (allows me to select: Customer or Prospet)

                So far just learned that I can't edit data cCustStatus since it is a calculated field. Any suggestions as to setting this up?
                I got the cartisan(x) relationship to work just fine....but the CustStatus join isn't agreeing with me and my great abilities of programming.

                Much thanks.


                • 5. Re: Main Menu Question

                  Hi Jay,

                  If I follow, you have a table CustomerInfo.  And you have duplicated CustomerInfo in your graph and named it CustomerInfoList.  When on a layout based upon CustomerInfo, you want to see a portal of ALL customers. 

                  If instead, you want to see all customers in the portal that are of the same CustStatus as the customer you are viewing, then the relationship would be:

                  CustomerInfo::CustStatus = CustomerInfoList::CustStatus

                  But if you want to present the User with a global text field where they can select the customer type to view in the portal, then you need to create a global text field in CustomerInfo (maybe call it gStatus ... the 'g' meaning global storage).  It should not be a calculation.  Place CustomerInfo::gStatus above the portal and attach a pop-up or checkbox based upon value list 'all values' from CustStatus.  The relationship should be set up as:

                  CustomerInfo::gStatus = CustomerInfoList::CustStatus

                  • 6. Re: Main Menu Question

                    Absolutely....Fabulous!!! Just what I needed...I guess I didn't need that cartisan join(X) at all.

                    Thanks for your help...

                    What would you use the (X)cartisan join for anyway?


                    • 7. Re: Main Menu Question

                      The Cartesian Product Operator is used to join all records in a second table to all records in the first.  It used to be required to add a constant (such as 1) in both tables and relate them but since Cartesian, those constant fields are no longer required.  So your second table doesn't need to match the first table in any way.

                      In fact, you can join any two fields (one from each table) and they do not need to be the same data type; they do not need to match; they can both be global fields even; and the fields can be empty.  Any field except container or summary can be used.

                      To make Cartesian joins obvious to me, I like to create dummy fields in both tables, create the Cartesian join, and then delete the two fields back out.  This produces a match from the table header to the table header so it is clearly a Cartesian and it does not get tangled in the other relationships below.

                      • 8. Re: Main Menu Question

                        Hello, I did notice just one glitch and that is when I click on the customer name on portal the scroll bar resets it self...and I did
                        uncheck the box in portal setup so that it wouldn't do that...not sure why the scroll bar wants to reset itself. 

                        Relationship is setup as described below:

                        CustomerInfo       CustomerInfoList(TO)
                                gCustId  =   CustId

                        Layout is CustomerInfo with a portal based on CustomerInfoList

                        I have a script setup to capture variable of the CustID and then simply perform a find to show that customer on the same layout.

                        Any suggestions would be great.  Jay.