Alternate portal filters?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Alternate portal filters?

Stephen Wonfor-3
Hi

Filemaker 15 on Server 15.
I have a number of portals in a client Dashboard that are used for quick views of what is up, going to be up and has been up.
More users means more possible choices.
I use 3 checkbox globals to allow the “filtering” of the portal data - date range, course type, internal/external.  So my join is aiming the three globals at three “real” data fields in the underlying table.
One of the users would rather see the portal data filtered by number of attendees and location.
Is it possible to create a portal that accepts criteria from different groups of fields? I can’t find anything reasonable in the Relationships graph that would allow this.

My best solution has been to use object hiding to show one portal that uses one rule set and another portal with the other rule set.  The hiding is turned off and on based upon which fields contain “data”.  Fine but then needs script triggers to nuke all the group 1 fields if the user makes a selection in a group 2 field.

I keep thinking I am missing something in the graph.

Stephen

...

Cunningham's law – The best way to get the right answer on the Internet is not to ask a question, it’s to post the wrong answer.

_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Alternate portal filters?

Kevin Frank
Hi Stephen,

Instead of using the built-in filtering mechanism, portal "filtering"
can be implemented at the relational level, by using a global text field
as the "primary" predicate, the primary key of the child table as the
"foreign" predicate, and then scriptomatically inserting/updating a
stack of child IDs in the global field as necessary. This global field
is often referred to as a multiline key (MLK), and this methodology has
a number of advantages over standard portal filtering, including...

  * it's faster
  * it's more flexible
  * you don't have to modify table/field/graph schema when requirements
    change
  * since it's relationship-based you can sum/count/etc the rows
  * you can GTRR to the corresponding set of children

So to be clear, with this methodology, you do not use standard portal
filtering at all.

Kevin

P.S. this methodology has worked reliably since FMP 3.0 was released
more than 20 years ago.

-------------------------------------------------------
Kevin Frank & Associates
[hidden email]
www.kevinfrank.com
707-822-6414
-------------------------------------------------------
FileMaker 7/8/9/10/11/12/13/14/15 Certified
-------------------------------------------------------
blog: www.filemakerhacks.com

Stephen Wonfor wrote:

> Hi
>
> Filemaker 15 on Server 15.
> I have a number of portals in a client Dashboard that are used for quick views of what is up, going to be up and has been up.
> More users means more possible choices.
> I use 3 checkbox globals to allow the “filtering” of the portal data - date range, course type, internal/external.  So my join is aiming the three globals at three “real” data fields in the underlying table.
> One of the users would rather see the portal data filtered by number of attendees and location.
> Is it possible to create a portal that accepts criteria from different groups of fields? I can’t find anything reasonable in the Relationships graph that would allow this.
>
> My best solution has been to use object hiding to show one portal that uses one rule set and another portal with the other rule set.  The hiding is turned off and on based upon which fields contain “data”.  Fine but then needs script triggers to nuke all the group 1 fields if the user makes a selection in a group 2 field.
>
> I keep thinking I am missing something in the graph.
>
> Stephen
>
> ...
>
> Cunningham's law – The best way to get the right answer on the Internet is not to ask a question, it’s to post the wrong answer.
>
> _______________________________________________
> FMPexperts mailing list
> [hidden email]
> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au

_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Alternate portal filters?

Richard DeShong
Hi Stephen,

Another approach is a modification of your current approach - which is
using a global-to-field relationship.  The problem is that a user might
not have a selection for a given criteria.  It looks like you want 5
criteria:

Date,  Course,  Int/Ext,  Count,  and Location.

If you create a relationship using 5 globals pointing at those 5 fields,
and the user does not care about "Location", then what do you put in the
Location global?  If you leave the global Location empty, then the
relationship will only see rcds with an empty Location - no matter what
is put in the other globals.

How to make it work:  Create 5 calc fields based on the five criteria
fields.  The calc fields are all type "text".  The value is the original
field value, a pilcro, and the text "Any" (or whatever is appropriate
for "I don't care").

Now point your globals to the calc versions.  Put "Any" into all the
globals and you should see all records.

Dates and ranges require some "under-the-hood" work, but they are doable.

caveat:  It was years ago that I set this, so I might not be explaining
is correctly.


On 5/17/2017 3:47 PM, Kevin Frank wrote:

> Hi Stephen,
>
> Instead of using the built-in filtering mechanism, portal "filtering"
> can be implemented at the relational level, by using a global text
> field as the "primary" predicate, the primary key of the child table
> as the "foreign" predicate, and then scriptomatically
> inserting/updating a stack of child IDs in the global field as
> necessary. This global field is often referred to as a multiline key
> (MLK), and this methodology has a number of advantages over standard
> portal filtering, including...
>
>  * it's faster
>  * it's more flexible
>  * you don't have to modify table/field/graph schema when requirements
>    change
>  * since it's relationship-based you can sum/count/etc the rows
>  * you can GTRR to the corresponding set of children
>
> So to be clear, with this methodology, you do not use standard portal
> filtering at all.
>
> Kevin
>
> P.S. this methodology has worked reliably since FMP 3.0 was released
> more than 20 years ago.
>
> -------------------------------------------------------
> Kevin Frank & Associates
> [hidden email]
> www.kevinfrank.com
> 707-822-6414
> -------------------------------------------------------
> FileMaker 7/8/9/10/11/12/13/14/15 Certified
> -------------------------------------------------------
> blog: www.filemakerhacks.com
>
> Stephen Wonfor wrote:
>> Hi
>>
>> Filemaker 15 on Server 15.
>> I have a number of portals in a client Dashboard that are used for
>> quick views of what is up, going to be up and has been up.
>> More users means more possible choices.
>> I use 3 checkbox globals to allow the “filtering” of the portal data
>> - date range, course type, internal/external.  So my join is aiming
>> the three globals at three “real” data fields in the underlying table.
>> One of the users would rather see the portal data filtered by number
>> of attendees and location.
>> Is it possible to create a portal that accepts criteria from
>> different groups of fields? I can’t find anything reasonable in the
>> Relationships graph that would allow this.
>>
>> My best solution has been to use object hiding to show one portal
>> that uses one rule set and another portal with the other rule set.  
>> The hiding is turned off and on based upon which fields contain
>> “data”.  Fine but then needs script triggers to nuke all the group 1
>> fields if the user makes a selection in a group 2 field.
>>
>> I keep thinking I am missing something in the graph.
>>
>> Stephen
>>
>> ...
>>
>> Cunningham's law – The best way to get the right answer on the
>> Internet is not to ask a question, it’s to post the wrong answer.
>>
>> _______________________________________________
>> FMPexperts mailing list
>> [hidden email]
>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>
> _______________________________________________
> FMPexperts mailing list
> [hidden email]
> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au

--
Richard DeShong
Logic Tools
510-642-5123 office
925-285-1088 cell

_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Alternate portal filters?

Tom Fitch
In reply to this post by Kevin Frank
An added benefit of using Kevin's suggestion is you can then implement
dynamic sorting in your portal in a fairly sane way with the addition
of one simple field in your related table (see fitchandfitch.com for
details).

Tom Fitch
FileMaker Pro Certified Developer
Portland, Oregon


On Wed, May 17, 2017 at 3:47 PM, Kevin Frank <[hidden email]> wrote:

> Hi Stephen,
>
> Instead of using the built-in filtering mechanism, portal "filtering" can be
> implemented at the relational level, by using a global text field as the
> "primary" predicate, the primary key of the child table as the "foreign"
> predicate, and then scriptomatically inserting/updating a stack of child IDs
> in the global field as necessary. This global field is often referred to as
> a multiline key (MLK), and this methodology has a number of advantages over
> standard portal filtering, including...
>
>  * it's faster
>  * it's more flexible
>  * you don't have to modify table/field/graph schema when requirements
>    change
>  * since it's relationship-based you can sum/count/etc the rows
>  * you can GTRR to the corresponding set of children
>
> So to be clear, with this methodology, you do not use standard portal
> filtering at all.
>
> Kevin
>
> P.S. this methodology has worked reliably since FMP 3.0 was released more
> than 20 years ago.
>
> -------------------------------------------------------
> Kevin Frank & Associates
> [hidden email]
> www.kevinfrank.com
> 707-822-6414
> -------------------------------------------------------
> FileMaker 7/8/9/10/11/12/13/14/15 Certified
> -------------------------------------------------------
> blog: www.filemakerhacks.com
>
>
> Stephen Wonfor wrote:
>>
>> Hi
>>
>> Filemaker 15 on Server 15.
>> I have a number of portals in a client Dashboard that are used for quick
>> views of what is up, going to be up and has been up.
>> More users means more possible choices.
>> I use 3 checkbox globals to allow the “filtering” of the portal data -
>> date range, course type, internal/external.  So my join is aiming the three
>> globals at three “real” data fields in the underlying table.
>> One of the users would rather see the portal data filtered by number of
>> attendees and location.
>> Is it possible to create a portal that accepts criteria from different
>> groups of fields? I can’t find anything reasonable in the Relationships
>> graph that would allow this.
>>
>> My best solution has been to use object hiding to show one portal that
>> uses one rule set and another portal with the other rule set.  The hiding is
>> turned off and on based upon which fields contain “data”.  Fine but then
>> needs script triggers to nuke all the group 1 fields if the user makes a
>> selection in a group 2 field.
>>
>> I keep thinking I am missing something in the graph.
>>
>> Stephen
>>
>> ...
>>
>> Cunningham's law – The best way to get the right answer on the Internet is
>> not to ask a question, it’s to post the wrong answer.
>>
>> _______________________________________________
>> FMPexperts mailing list
>> [hidden email]
>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>
>
> _______________________________________________
> FMPexperts mailing list
> [hidden email]
> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Alternate portal filters?

Stephen Wonfor-3
Kevin, Richard and Tom

If I read this all correctly I create a multi-key field using the globals on one end and point them at a derived multi-key at the other end using a stacked calc of the five target fields.  I recall the MK method from back in the mists of Filemaker time, then forgot about it when the transition to FMP7 occurred.  I had thought it had become obsolete.

Kevin - btw - have you read “We Are Legion” by Dennis Taylor?  Very fun scifi tale with resonant echoes of “Ready Player One” in tone and texture.  The audible book read by Ray Porter is a real gem.  Third book in the “Bobiverse” due out in August.

Stephen

----------

"An associate producer is the only guy in Hollywood who will associate with a producer." ---Fred Allen

> On May 17, 2017, at 5:36 PM, Tom Fitch <[hidden email]> wrote:
>
> An added benefit of using Kevin's suggestion is you can then implement
> dynamic sorting in your portal in a fairly sane way with the addition
> of one simple field in your related table (see fitchandfitch.com for
> details).
>
> Tom Fitch
> FileMaker Pro Certified Developer
> Portland, Oregon
>
>
> On Wed, May 17, 2017 at 3:47 PM, Kevin Frank <[hidden email]> wrote:
>> Hi Stephen,
>>
>> Instead of using the built-in filtering mechanism, portal "filtering" can be
>> implemented at the relational level, by using a global text field as the
>> "primary" predicate, the primary key of the child table as the "foreign"
>> predicate, and then scriptomatically inserting/updating a stack of child IDs
>> in the global field as necessary. This global field is often referred to as
>> a multiline key (MLK), and this methodology has a number of advantages over
>> standard portal filtering, including...
>>
>> * it's faster
>> * it's more flexible
>> * you don't have to modify table/field/graph schema when requirements
>>   change
>> * since it's relationship-based you can sum/count/etc the rows
>> * you can GTRR to the corresponding set of children
>>
>> So to be clear, with this methodology, you do not use standard portal
>> filtering at all.
>>
>> Kevin
>>
>> P.S. this methodology has worked reliably since FMP 3.0 was released more
>> than 20 years ago.
>>
>> -------------------------------------------------------
>> Kevin Frank & Associates
>> [hidden email]
>> www.kevinfrank.com
>> 707-822-6414
>> -------------------------------------------------------
>> FileMaker 7/8/9/10/11/12/13/14/15 Certified
>> -------------------------------------------------------
>> blog: www.filemakerhacks.com
>>
>>
>> Stephen Wonfor wrote:
>>>
>>> Hi
>>>
>>> Filemaker 15 on Server 15.
>>> I have a number of portals in a client Dashboard that are used for quick
>>> views of what is up, going to be up and has been up.
>>> More users means more possible choices.
>>> I use 3 checkbox globals to allow the “filtering” of the portal data -
>>> date range, course type, internal/external.  So my join is aiming the three
>>> globals at three “real” data fields in the underlying table.
>>> One of the users would rather see the portal data filtered by number of
>>> attendees and location.
>>> Is it possible to create a portal that accepts criteria from different
>>> groups of fields? I can’t find anything reasonable in the Relationships
>>> graph that would allow this.
>>>
>>> My best solution has been to use object hiding to show one portal that
>>> uses one rule set and another portal with the other rule set.  The hiding is
>>> turned off and on based upon which fields contain “data”.  Fine but then
>>> needs script triggers to nuke all the group 1 fields if the user makes a
>>> selection in a group 2 field.
>>>
>>> I keep thinking I am missing something in the graph.
>>>
>>> Stephen
>>>
>>> ...
>>>
>>> Cunningham's law – The best way to get the right answer on the Internet is
>>> not to ask a question, it’s to post the wrong answer.
>>>
>>> _______________________________________________
>>> FMPexperts mailing list
>>> [hidden email]
>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>>
>>
>> _______________________________________________
>> FMPexperts mailing list
>> [hidden email]
>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
> _______________________________________________
> FMPexperts mailing list
> [hidden email]
> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au

_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Alternate portal filters?

Tom Fitch
Not exactly. I believe Richard is talking about a derived multi-key in
the child table, consisting of the value plus "Any" for each field,
and a relationship using all five fields on both sides of the
relationship. Kevin and I are talking about a multi-key on the parent
side, the keys being just the primary keys, which are then related to
the primary key in the child. The job there is to gather the keys into
the list, which you could do via SQL or whatever method you're
comfortable with.

Tom Fitch
FileMaker Pro Certified Developer
Portland, Oregon


On Wed, May 17, 2017 at 8:58 PM, Stephen Wonfor <[hidden email]> wrote:

> Kevin, Richard and Tom
>
> If I read this all correctly I create a multi-key field using the globals on one end and point them at a derived multi-key at the other end using a stacked calc of the five target fields.  I recall the MK method from back in the mists of Filemaker time, then forgot about it when the transition to FMP7 occurred.  I had thought it had become obsolete.
>
> Kevin - btw - have you read “We Are Legion” by Dennis Taylor?  Very fun scifi tale with resonant echoes of “Ready Player One” in tone and texture.  The audible book read by Ray Porter is a real gem.  Third book in the “Bobiverse” due out in August.
>
> Stephen
>
> ----------
>
> "An associate producer is the only guy in Hollywood who will associate with a producer." ---Fred Allen
>
>> On May 17, 2017, at 5:36 PM, Tom Fitch <[hidden email]> wrote:
>>
>> An added benefit of using Kevin's suggestion is you can then implement
>> dynamic sorting in your portal in a fairly sane way with the addition
>> of one simple field in your related table (see fitchandfitch.com for
>> details).
>>
>> Tom Fitch
>> FileMaker Pro Certified Developer
>> Portland, Oregon
>>
>>
>> On Wed, May 17, 2017 at 3:47 PM, Kevin Frank <[hidden email]> wrote:
>>> Hi Stephen,
>>>
>>> Instead of using the built-in filtering mechanism, portal "filtering" can be
>>> implemented at the relational level, by using a global text field as the
>>> "primary" predicate, the primary key of the child table as the "foreign"
>>> predicate, and then scriptomatically inserting/updating a stack of child IDs
>>> in the global field as necessary. This global field is often referred to as
>>> a multiline key (MLK), and this methodology has a number of advantages over
>>> standard portal filtering, including...
>>>
>>> * it's faster
>>> * it's more flexible
>>> * you don't have to modify table/field/graph schema when requirements
>>>   change
>>> * since it's relationship-based you can sum/count/etc the rows
>>> * you can GTRR to the corresponding set of children
>>>
>>> So to be clear, with this methodology, you do not use standard portal
>>> filtering at all.
>>>
>>> Kevin
>>>
>>> P.S. this methodology has worked reliably since FMP 3.0 was released more
>>> than 20 years ago.
>>>
>>> -------------------------------------------------------
>>> Kevin Frank & Associates
>>> [hidden email]
>>> www.kevinfrank.com
>>> 707-822-6414
>>> -------------------------------------------------------
>>> FileMaker 7/8/9/10/11/12/13/14/15 Certified
>>> -------------------------------------------------------
>>> blog: www.filemakerhacks.com
>>>
>>>
>>> Stephen Wonfor wrote:
>>>>
>>>> Hi
>>>>
>>>> Filemaker 15 on Server 15.
>>>> I have a number of portals in a client Dashboard that are used for quick
>>>> views of what is up, going to be up and has been up.
>>>> More users means more possible choices.
>>>> I use 3 checkbox globals to allow the “filtering” of the portal data -
>>>> date range, course type, internal/external.  So my join is aiming the three
>>>> globals at three “real” data fields in the underlying table.
>>>> One of the users would rather see the portal data filtered by number of
>>>> attendees and location.
>>>> Is it possible to create a portal that accepts criteria from different
>>>> groups of fields? I can’t find anything reasonable in the Relationships
>>>> graph that would allow this.
>>>>
>>>> My best solution has been to use object hiding to show one portal that
>>>> uses one rule set and another portal with the other rule set.  The hiding is
>>>> turned off and on based upon which fields contain “data”.  Fine but then
>>>> needs script triggers to nuke all the group 1 fields if the user makes a
>>>> selection in a group 2 field.
>>>>
>>>> I keep thinking I am missing something in the graph.
>>>>
>>>> Stephen
>>>>
>>>> ...
>>>>
>>>> Cunningham's law – The best way to get the right answer on the Internet is
>>>> not to ask a question, it’s to post the wrong answer.
>>>>
>>>> _______________________________________________
>>>> FMPexperts mailing list
>>>> [hidden email]
>>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>>>
>>>
>>> _______________________________________________
>>> FMPexperts mailing list
>>> [hidden email]
>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>> _______________________________________________
>> FMPexperts mailing list
>> [hidden email]
>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>
> _______________________________________________
> FMPexperts mailing list
> [hidden email]
> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Alternate portal filters?

Richard DeShong
Right, Tom.  Hi Stephen, I was "fixing" what I understood to be your
current setup - global fields in the Parent related to regular fields in
the Child.  In your case, 5 global fields in Parent related to 5
calculation fields in Child.  As Tom mentioned, the calculation is
simply List( <field> ; "Any" ).  This allows you to put "Any" into the
Parent globals to see all records, and they put a user selected value to
limit the records.

Kevin's method is a replacement of what you are doing.  You have a
single global in the Parent related to a unique key in the Child.  When
the user makes a selection for a criteria, you script a find in the
Child table (or use SQL) and collect a list of record keys from the
found set.  Then set the Parent global to that list.


On 5/17/2017 9:38 PM, Tom Fitch wrote:

> Not exactly. I believe Richard is talking about a derived multi-key in
> the child table, consisting of the value plus "Any" for each field,
> and a relationship using all five fields on both sides of the
> relationship. Kevin and I are talking about a multi-key on the parent
> side, the keys being just the primary keys, which are then related to
> the primary key in the child. The job there is to gather the keys into
> the list, which you could do via SQL or whatever method you're
> comfortable with.
>
> Tom Fitch
> FileMaker Pro Certified Developer
> Portland, Oregon
>
>
> On Wed, May 17, 2017 at 8:58 PM, Stephen Wonfor <[hidden email]> wrote:
>> Kevin, Richard and Tom
>>
>> If I read this all correctly I create a multi-key field using the globals on one end and point them at a derived multi-key at the other end using a stacked calc of the five target fields.  I recall the MK method from back in the mists of Filemaker time, then forgot about it when the transition to FMP7 occurred.  I had thought it had become obsolete.
>>
>> Kevin - btw - have you read “We Are Legion” by Dennis Taylor?  Very fun scifi tale with resonant echoes of “Ready Player One” in tone and texture.  The audible book read by Ray Porter is a real gem.  Third book in the “Bobiverse” due out in August.
>>
>> Stephen
>>
>> ----------
>>
>> "An associate producer is the only guy in Hollywood who will associate with a producer." ---Fred Allen
>>
>>> On May 17, 2017, at 5:36 PM, Tom Fitch <[hidden email]> wrote:
>>>
>>> An added benefit of using Kevin's suggestion is you can then implement
>>> dynamic sorting in your portal in a fairly sane way with the addition
>>> of one simple field in your related table (see fitchandfitch.com for
>>> details).
>>>
>>> Tom Fitch
>>> FileMaker Pro Certified Developer
>>> Portland, Oregon
>>>
>>>
>>> On Wed, May 17, 2017 at 3:47 PM, Kevin Frank <[hidden email]> wrote:
>>>> Hi Stephen,
>>>>
>>>> Instead of using the built-in filtering mechanism, portal "filtering" can be
>>>> implemented at the relational level, by using a global text field as the
>>>> "primary" predicate, the primary key of the child table as the "foreign"
>>>> predicate, and then scriptomatically inserting/updating a stack of child IDs
>>>> in the global field as necessary. This global field is often referred to as
>>>> a multiline key (MLK), and this methodology has a number of advantages over
>>>> standard portal filtering, including...
>>>>
>>>> * it's faster
>>>> * it's more flexible
>>>> * you don't have to modify table/field/graph schema when requirements
>>>>    change
>>>> * since it's relationship-based you can sum/count/etc the rows
>>>> * you can GTRR to the corresponding set of children
>>>>
>>>> So to be clear, with this methodology, you do not use standard portal
>>>> filtering at all.
>>>>
>>>> Kevin
>>>>
>>>> P.S. this methodology has worked reliably since FMP 3.0 was released more
>>>> than 20 years ago.
>>>>
>>>> -------------------------------------------------------
>>>> Kevin Frank & Associates
>>>> [hidden email]
>>>> www.kevinfrank.com
>>>> 707-822-6414
>>>> -------------------------------------------------------
>>>> FileMaker 7/8/9/10/11/12/13/14/15 Certified
>>>> -------------------------------------------------------
>>>> blog: www.filemakerhacks.com
>>>>
>>>>
>>>> Stephen Wonfor wrote:
>>>>> Hi
>>>>>
>>>>> Filemaker 15 on Server 15.
>>>>> I have a number of portals in a client Dashboard that are used for quick
>>>>> views of what is up, going to be up and has been up.
>>>>> More users means more possible choices.
>>>>> I use 3 checkbox globals to allow the “filtering” of the portal data -
>>>>> date range, course type, internal/external.  So my join is aiming the three
>>>>> globals at three “real” data fields in the underlying table.
>>>>> One of the users would rather see the portal data filtered by number of
>>>>> attendees and location.
>>>>> Is it possible to create a portal that accepts criteria from different
>>>>> groups of fields? I can’t find anything reasonable in the Relationships
>>>>> graph that would allow this.
>>>>>
>>>>> My best solution has been to use object hiding to show one portal that
>>>>> uses one rule set and another portal with the other rule set.  The hiding is
>>>>> turned off and on based upon which fields contain “data”.  Fine but then
>>>>> needs script triggers to nuke all the group 1 fields if the user makes a
>>>>> selection in a group 2 field.
>>>>>
>>>>> I keep thinking I am missing something in the graph.
>>>>>
>>>>> Stephen
>>>>>
>>>>> ...
>>>>>
>>>>> Cunningham's law – The best way to get the right answer on the Internet is
>>>>> not to ask a question, it’s to post the wrong answer.
>>>>>
>>>>> _______________________________________________
>>>>> FMPexperts mailing list
>>>>> [hidden email]
>>>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>>>>
>>>> _______________________________________________
>>>> FMPexperts mailing list
>>>> [hidden email]
>>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>>> _______________________________________________
>>> FMPexperts mailing list
>>> [hidden email]
>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>> _______________________________________________
>> FMPexperts mailing list
>> [hidden email]
>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
> _______________________________________________
> FMPexperts mailing list
> [hidden email]
> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au

--
Richard DeShong
Logic Tools
510-642-5123 office
925-285-1088 cell

_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
Loading...