Update 2nd portal listwhen click the 1st portal...

[zukutu]

Hi everybody,

i need help please

i'm trying to create a simple membership database,

where i can store the date when they create their card and when it will expired. and also, maintain the type of membership.

if, they choose "family" then they need to fill out the groupInfo portal.

Problems:

1. if they choose "family" in their first period of their membership, and renew it as "individual", the groupInfo portal doesn't go empty.

2. if i click on the any of the row (history portal), the groupInfo portal show the same list. what i want is to filter it out (family and individual).

(i want it to works like the history layout)

What should i change ?? or add ?? create???

before that... thanks in advance

uri

*just student

Membership.zip

[Gary Weisbrodt]

Came across this this morning. Perhaps it can do what you want.

[zukutu]

Hi Gary... thank you for your reply.

What i'm looking for is more like this

http://www.watzmanassociates.com/roomdex/rdprefs.html

So everytime i click on the building name, the room name will change.

But, i still can't figure it out how the logic works.. hehehe

anyway.. thank you =)

uri

*just student

[Ugo DI LUCA]

Hi,

I suppose the lower portal in your files should only show the Family group for the current year membership.

Therefore, you may consider having a relationship with a compound of ID and Period.

[zukutu]

HI Ugo DI LUCA,

thank you fro your reply..

hehehe... my bad...

i think my explaination was not clear. sorry..

ok..

this is what i'm looking for.

-- if i click the row in "history" portal where the type = "family", the "group" portal will show the name of family member.

-- and when i click the row where type = "individual", the "group" portal will not show any family member's name ??

how can i do that : do i need to create self relationship ??

thank you again... and sorry about the the confusion...=)

[Ugo DI LUCA]

Hi,

Sorry for that, but it didn't (and still doesn't) make much sense for me that this Group portal disappears if the second row of the History portal is modified, as was your intent in the original post.

If I can remember (don't have v7 here right now), the second portal isnt tied to the History but to the Member ID, so at the moment, the History portal would have no effect whatsoever to what the Group Portal displays.

That's why I suggested that your family members be entered in the 'Join Table' using a concanation of both the Member ID and the Membership period.

Actually, I'd suggest not using portals for data entry, and rather using the new v7 functionality of a new window with a Group Window entry appearing or not, based on the Membership type selected for the period. Actually, a new Membership would be processed through another Window too, and not entered directly through a portal.

For data browsing now, which is what you lately ask, what you're looking for is a way to dynamically show (or not) the list of familiars tied to the Member ID, according to the Membership period.

As you can see, the Membership Period (would this be entered as dates or an ID) must be used as a key, combined to the Member ID.

Each row of the History portal has a button that sets a temporary key for the other portal so that the list updates.

So yes you need another key for the Group Portal, and you may have it default to the latest Membership period, which would be logical.

Finally, I can't remember how the family members axactly are stored, and how easily you may one day convert a group member to a proper Member. It might be interresting to account for this probable need.

Hope I'm not confusing you much than necessary. Tell if you need more help for the last steps outlined.

[zukutu]

hi Ugo DI LUCA,

thank you for your reply.

I just found some example that similar to the problem that i'm facing right now.

http://www.watzmanassociates.com/roomdex/rddesc.html "RoomDex"

on the "Pref" layout. You'll notice there are Building Name and Room Name portal.

What I want to do is, similar to this.

When we click on the Building Name list, the Room Name list change.

How the logic works : I mean, we click on one portal, the list on the other portal change. How the script works :

once again.. thank you..

uri

*just student.

[-Queue-]

I think the script would be very simple. It only need set a field to change the relationship. If the relationship to the Room table is based on the Building ID (I would assume global to text), then you only have to set the global to the newly selected Building ID. Set Field [gBuildingID; relationship::BuildingID], where relationship is the one used for the main portal, should do it.