relations

FMP 9 adv, Win XP

I must have done this before, i'm pretty sure... But my brain has gone
blank.
I have a fashion catalogue system set up. This tracks pictures of fashion.
It records
Male / Female
Era ( by year and by century)
Formal / Casual
You get the idea

Now i want a filtering relation, so that when I slect Male I see all males,
when I select casual I see all casual and when I select Male and casual I
only get Males that have a casual outfit. The problem is the last bit. There
are so many combinations possible that I will never be able to write a
calculation that holds them all. A simple relation based on AND returns
males AND casual. Thus displaying all Females as well. I feel stupid. On top
of this a picture might hold a male and a female. The value for this is
entered in a textfield by a value list and check-boxes. So searching for M
or F might also turn out in search for M AND F. And I want to use a relation
so I can use a portal. By which the use directly has a hold of what he is
doing.

So who gets me going?

Keep well, Ursus

Re: relations

On Sep 30, 9:17 pm, "Ursus" wrote:
> FMP 9 adv, Win XP
>
> I must have done this before, i'm pretty sure... But my brain has gone
> blank.
> I have a fashion catalogue system set up. This tracks pictures of fashion.
> It records
> Male / Female
> Era ( by year and by century)
> Formal / Casual
> You get the idea
>
> Now i want a filtering relation, so that when I slect Male I see all males,
> when I select casual I see all casual and when I select Male and casual I
> only get Males that have a casual outfit. The problem is the last bit. There
> are so many combinations possible that I will never be able to write a
> calculation that holds them all. A simple relation based on AND returns
> males AND casual. Thus displaying all Females as well. I feel stupid. On top
> of this a picture might hold a male and a female. The value for this is
> entered in a textfield by a value list and check-boxes. So searching for M
> or F might also turn out in search for M AND F. And I want to use a relation
> so I can use a portal. By which the use directly has a hold of what he is
> doing.
>
> So who gets me going?
>
> Keep well, Ursus


Let's see...The way I would handle it would be to create a calculated
field in the child table for each field you plan on using in the
filter. Assuming a null value in a field would return all the
records, that calc would be
cField = Case( not isEmpty(Field); Field & P & 1; 1)

I would also create two fields for each filter in the parent table.
Both are globals, one is a calculated global. The straight globals
would be the selection fields...a drop down menu with a list of
possible values (ie, Men/Women, Casual/Formal, etc) for user
interaction. The second global would be calculated for the actual
relationship and would be
cgSelection = Case(not isEmpty(gSelection); gSelection; 1)

Related cgSelection for each filter field with it's respective cField
and I think you're good to go.

G

*P refers to the pilcrow character.

Re: relations

>>
>> Now i want a filtering relation, so that when I slect Male I see all
>> males,
>> when I select casual I see all casual and when I select Male and casual I
>> only get Males that have a casual outfit. The problem is the last bit.
>> There
>> are so many combinations possible that I will never be able to write a
>> calculation that holds them all. A simple relation based on AND returns
>> males AND casual. Thus displaying all Females as well. I feel stupid. On
>> top
>> of this a picture might hold a male and a female. The value for this is
>> entered in a textfield by a value list and check-boxes. So searching for
>> M
>> or F might also turn out in search for M AND F. And I want to use a
>> relation
>> so I can use a portal. By which the use directly has a hold of what he is
>> doing.
>>
>> So who gets me going?
>>
>> Keep well, Ursus
>
>
> Let's see...The way I would handle it would be to create a calculated
> field in the child table for each field you plan on using in the
> filter. Assuming a null value in a field would return all the
> records, that calc would be
> cField = Case( not isEmpty(Field); Field & P & 1; 1)
>
> I would also create two fields for each filter in the parent table.
> Both are globals, one is a calculated global. The straight globals
> would be the selection fields...a drop down menu with a list of
> possible values (ie, Men/Women, Casual/Formal, etc) for user
> interaction. The second global would be calculated for the actual
> relationship and would be
> cgSelection = Case(not isEmpty(gSelection); gSelection; 1)
>
> Related cgSelection for each filter field with it's respective cField
> and I think you're good to go.
>

Thanks Gript, but I think my explanation was faulted.

The user will have multiple choises to make. Every time he makes a choise
the list dwindles down.
So when he checks Male he sees 100 records in a portal
When he then also checks Formal the number of related records goes down to
say 45 ( all males that show formal dress )
When he then selects White from the colors he is left with the two records
showing male, formal dress, white.
The point being the user can go back and change only male to female and he
will have 500 records ( female, formal, white [which contains all bridal
dress])

Keep well, Ursus

Re: relations

On Sun, 30 Sep 2007 21:17:54 +0200, "Ursus"
wrote:

>FMP 9 adv, Win XP
>
>I must have done this before, i'm pretty sure... But my brain has gone
>blank.
>I have a fashion catalogue system set up. This tracks pictures of fashion.
>It records
>Male / Female
>Era ( by year and by century)
>Formal / Casual
>You get the idea
>
>Now i want a filtering relation, so that when I slect Male I see all males,
>when I select casual I see all casual and when I select Male and casual I
>only get Males that have a casual outfit. The problem is the last bit. There
>are so many combinations possible that I will never be able to write a
>calculation that holds them all. A simple relation based on AND returns
>males AND casual. Thus displaying all Females as well. I feel stupid. On top
>of this a picture might hold a male and a female. The value for this is
>entered in a textfield by a value list and check-boxes. So searching for M
>or F might also turn out in search for M AND F. And I want to use a relation
>so I can use a portal. By which the use directly has a hold of what he is
>doing.
>
>So who gets me going?

You could create a calculated field for each checkbox:

n_checkbox_calc = 0 = IsEmpty ( n_checkbox )

.... so that if a checkbox is checked, "1" is returned, and if
unchecked, "0" is returned. Then you can search and filter based on
any combination of checkbox data.

hope this helps

--
FW

FileMaker Pro 8.5 under Win XP Pro, and
FileMaker Server 8.0 under Win 2003 Server

Re: relations

On Oct 1, 2:52 am, "Ursus" wrote:
> >> Now i want a filtering relation, so that when I slect Male I see all
> >> males,
> >> when I select casual I see all casual and when I select Male and casual I
> >> only get Males that have a casual outfit. The problem is the last bit.
> >> There
> >> are so many combinations possible that I will never be able to write a
> >> calculation that holds them all. A simple relation based on AND returns
> >> males AND casual. Thus displaying all Females as well. I feel stupid. On
> >> top
> >> of this a picture might hold a male and a female. The value for this is
> >> entered in a textfield by a value list and check-boxes. So searching for
> >> M
> >> or F might also turn out in search for M AND F. And I want to use a
> >> relation
> >> so I can use a portal. By which the use directly has a hold of what he is
> >> doing.
>
> >> So who gets me going?
>
> >> Keep well, Ursus
>
> > Let's see...The way I would handle it would be to create a calculated
> > field in the child table for each field you plan on using in the
> > filter. Assuming a null value in a field would return all the
> > records, that calc would be
> > cField = Case( not isEmpty(Field); Field & P & 1; 1)
>
> > I would also create two fields for each filter in the parent table.
> > Both are globals, one is a calculated global. The straight globals
> > would be the selection fields...a drop down menu with a list of
> > possible values (ie, Men/Women, Casual/Formal, etc) for user
> > interaction. The second global would be calculated for the actual
> > relationship and would be
> > cgSelection = Case(not isEmpty(gSelection); gSelection; 1)
>
> > Related cgSelection for each filter field with it's respective cField
> > and I think you're good to go.
>
> Thanks Gript, but I think my explanation was faulted.
>
> The user will have multiple choises to make. Every time he makes a choise
> the list dwindles down.
> So when he checks Male he sees 100 records in a portal
> When he then also checks Formal the number of related records goes down to
> say 45 ( all males that show formal dress )
> When he then selects White from the colors he is left with the two records
> showing male, formal dress, white.
> The point being the user can go back and change only male to female and he
> will have 500 records ( female, formal, white [which contains all bridal
> dress])
>
> Keep well, Ursus

I think you'll find my original post does most of what you want. You
want the portal to only show the related records that match the filter
fields, for blank filter fields, all records that meet the other
criteria should show. That's the my orginal post does.

But if you also want the user's choices to be narrowed down, rather
than simply showing an empty portal if a user selects a value
combination that doesn't exist. That's tricker and the best
explanation I've seen of hierarchal portals is here:

http://www.excelisys.com/services/fmp7/tips_tricks.htm