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.
The Computer Guy, Seattle
So I take it that that is the best way to do this....is to make another table for navigation purposes only.
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.
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
_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.
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
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?
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.
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:
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.