I have 10 Membership fields: memType1, memType2 etc...

These fields are on a "Setup" layout

To get to Setup, you click "Setup" on the main "Membership" window and another window opens and shows the setup layout. ok

There is a 'Membership::Type field that is dropdown that previously was hard code with membership types: Yearly, Honorary, 25 Year etc... I decided to implement a system whereby when a user leaves the Setup window, a concatendated string of the Memtype1&MemType2 etc. is formed and inserted into Members::XValueListHolder.

The Members::Type drop-down references Members::XValueListHolder as it's source. I CAN SEE Members::XValuelistHolder has the correct paragraph delimited content --&--#62; 25 Yr, 30 Yr, 50 Yr, Honorary...

When I click Members::Type drop-down it shows: 25 Yr, 40 Year, 55 Year, Honorary... ? Huh?

Since XValueLISTholder shows the correct content, I conclude that my script is working properly and that the Drop-Down is somehow holding old values and then combining them with my XvalueListHolder content.

Where could the drop-down be getting the ghost values?

Thank you for reading... and your ideas.

Some time has passed. Here is what I know.

a) Filemaker will not allow a Drop-Down based on a global field. (It can't be indexed)

The ghost entries seem to be caused by creating a 'non-global reference field. In this case a record created for the drop-down shows the then current dropdown list. I need all records to show the current Membership Type in the dropdown.

c) Creating a separate table (Called MembershipType) means I should use a portal to display the MemershipType (1-10) on the setup layout? The relationship would be between Membership::Type and MembershipType::Type ?

Am I headed in the right direction?

Edited March 15, 201213 yr by ron G

Skipped from the first sentence to the bottom, Ron.

I suggest a MembershipType table, with each record a different type (and each a unique ID). Any value list would be created from this table (ID MemType - just showing second value).

As for the interface to define MemTypes, typically a user is either taken to this table to enter a new record, or a portal is shown from a SYS table (cartesian join), a single record table (same one you might use for the Main Menu).

There are 2 layouts: Members and Setup

Setup is used to enter membership type (honorary, yearly etc)

Members holds member information: name, address etc...

The Setup layout is based on "Members"

The Members layout is based on "Members"

The "Members:Type" drop-down is based on the new table "MemTypepopup" which has 1 field: "MemType"

The "Members:Type" drop-down seems to work but it shows data when there is nothing in the MemtypePopup layout?

However, the portal (on the SETUP layout) just repeats the same entry... If I enter 'Honorary', for example, after I click out of the portal, all the rows of entered data show "Honorary". Huh?

The relationship is: Members::Type { --- } MemTypePopup::Memtype (many 2 many)

Skipped from the first sentence to the bottom, Ron.

I suggest a MembershipType table, with each record a different type (and each a unique ID). Any value list would be created from this table (ID MemType - just showing second value).

As for the interface to define MemTypes, typically a user is either taken to this table to enter a new record, or a portal is shown from a SYS table (cartesian join), a single record table (same one you might use for the Main Menu).

I have tried a X join between MEMBERS::Type X MembershipType::MemType. Only the top row can create records. Weird 1.

So, next I tried the same tables but put an = between them. Whatever I type into the first row repeats for all rows. Weird 2.

Next I try basing the SETUP layout on Members with each of the above combinqtions. Nope. Weird 3

Netxt I try and create a JOIN table (Another TO of Members) and link to it... with a = and when that fails with X. Both fail. Weird 4

Next I try putting the Portal DIRECTLY on the Members layout with all of the above combinations... Nope... Failure.. Weird 5

My teeth are just little stumps from grinding them for the last 2 days. Can you see what I am missing?

Thanks

Ron

"The Setup layout is based on "Members""

Right there is your problem. "Setup" or PREFs is typically a one record table. You need this table. Change "Setup" to be based on this table and create a cartesian relationship to MEMTYPES table. See demo.

Prefs.fp7.zip

Yes. Using the cartesian join 'x' works wonderfully but the portal can not add a new record without a 'New' button. That being said, I am going to 'go to school' on your method. I think it is 'cleaner' than what i came up with. Thank you for your thoughts and the sample code.

Ron

My mistake, yes, you cannot use a cartesian and have create records. You need to script the new record. As you'll see in my demo, it's pretty easy.