Keep users in found set?

[pctechtv]

This is the relationship I have. It really works well I can have unlimited Topics for a piece of Information. Meaning Subtopic for Topics and so on. I have created a couple scripts that can deduce what I am calling the family. What I mean by family is all the members under the Information, every Topic and its Subtopics no matter how deep. So now with this list, could it become something I could receive benefit from storing in another table? My intuition says definitely, but I just want to be sure this is the way to go. I really would like to have a way to keep users in “subject-matter” only the Information and its Topics and Subtopic. Is there a way to keep users locked in a found set only or is this done via Interface design.

[LaRetta]

I have created a couple scripts that can deduce what I am calling the family. What I mean by family is all the members under the Information, every Topic and its Subtopics no matter how deep. So now with this list, could it become something I could receive benefit from storing in another table? 

 

What is the purpose of producing this type of list?  Are you exporting?  I see no benefit of storing this structure in another table when 1) it can be accessed any time you need it since they are related and 2) it would not remain up to date and would need constant rewriting to keep it so; and if not up to date then it would NOT be as valuable.

 

Can you explain your thinking on why you want to do this and maybe we can better understand your need or are you mostly speculating to understand at a deeper level?  :-)

 

corrected ... added capitalised word NOT which completely changed the sentence.

Edited November 16, 2013 by LaRetta

[pctechtv]

Yes exactly I am speculating because I don't have enough experiance with complex relationships. I have a solution that is Information for solving problems basically I was thinking that it would make good sense to keep users in the subject matter. For example we have information we are storing for a setting for a piece of Computer Hardware so I would like to set it up where when in that information you only can see its Topics, Subtopics etc.There will be no neeed to see information about lighting for our video shoots. I was trying to work with the idea that a relationship could be used to only show those records based on the selection of that topic but I am lost how to set that up. This was a script I setup to deduce the members of a Information set

Set Variable [ $children; Value:getChildren ( INFORMATION::_kp_information_id) ]
Set Variable [ $i; Value:0 ]
Set Variable [ $j; Value:0 ]
Loop
        Set Variable [ $i; Value:$i + 1 ]
        If [ $i > ValueCount($children) ]
                Set Variable [ $i; Value: 1 ]
                Set Variable [ $j; Value:$j + 1 ]
                Set Variable [ $children; Value:getChildren(GetValue(INFORMATION::listall; $j)) ]
        End If
        Exit Loop If [ $i > ValueCount($children) ]
        Set Field [ INFORMATION::listall ; INFORMATION::listall & GetValue($children; $i) & "¶" ]
End Loop

I am also lost how this list would filter a relationship to only see the members it produces. I am thinking I would have to make a script trigger run it on record entering. I don't know if this is an advised way, or is just plain silly. I am working on other ways to produce the members i want in an Information set via a relationship or a calculation. really lost with this level of relationships. As time passes I keep understanding more.

[LaRetta]

"Is there a way to keep users locked in a found set only or is this done via Interface design."

 

This is done by removing User's ability to Find ( Enter Find Mode or Perform Find ), Extend found sets ( Constrain would be fine ), Show All, Show Omitted, or otherwise leave the layout (via script or manually) without your control so yes you are correct, via UI.  Custom Menus should always be implemented tightly (along with Security) and the developer should provide those functions.

 

"I have created a couple scripts that can deduce what I am calling the family. What I mean by family is all the members under the Information, every Topic and its Subtopics no matter how deep."

 

FM has already deduced this for you - that is why you have an indexed relational structure so there is no need to gather those IDs again.  Now if you needed to manipulate the tiers in alternate ways, sometimes gathering of IDs is beneficial for use in virtual table but I do not see that need here (from what is presented not taking into account what I do not know or possibly misunderstand).

 

"I really would like to have a way to keep users in “subject-matter” only the Information and its Topics and Subtopic."

 

I can only see Information and Topic in your graph - no SubTopic - but here is the piece I think you might be missing:

 

To quickly isolate all 'family records' associated to the INFORMATION record you are currently on, use the Go To Related [ ] script step.  Set it to match only current record (if fired from Information) and set the relationship to the LOWEST TIER in the relationship structure and go to a layout based upon that lowest tier table occurrence.  If it is a self-join, you can 'use current layout' as your landing site.  You then have a family record set which can easily be controlled now via UI.

 

"I am also lost how this list would filter a relationship to only see the members it produces."

 

But you DO understand how to use portals - I recall seeing a file of yours awhile back.  So you just place a portal based upon the table occurrence of the lowest tier.  

 

In FileMaker, every 'best' answer is based upon the correct details (and context and perspective, smile) so without specific examples, it is difficult to answer.  But I hope this moved you forward at least.  :-)

[LaRetta]

BTW, I notice that many of your posts were left without a follow up and I wonder if you might have unanswered questions on them which add to your 'feeling lost' now.  You are always welcome to post back and ask for clarification or to say something didn't work. And if it worked, letting us know that is nice also.

 

I like your spirit.

[pctechtv]

FM has already deduced this for you - that is why you have an indexed relational structure so there is no need to gather those IDs again.  Now if you needed to manipulate the tiers in alternate ways, sometimes gathering of IDs is beneficial for use in virtual table but I do not see that need here (from what is presented not taking into account what I do not know or possibly misunderstand).

Yes! I have been looking at it more and I get it now. I see what you are saying. That makes me understand the relationship a lot better. I have been doing some more studying and can see that I have been redoing a lot of the work that FileMaker already has done. Also this lets me see the power of the Found Set. In some training I have been using the instructor goes through a process of saving and restoring Found Sets. Can or should the members found set be stored as a variable or do you just have to collect the members (in this case ID's) into a list to do that? Thanks

[Fenton]

There are different possibilities of saving found sets, I suppose. But I have one simple one that I've used often. It is basically for saving the found set before trying some Find(s), which may or may not work well; so you can quickly get back to this saved one. It is fairly easy to build, fast to run, and fairly easy to use; basically 2 buttons, a nice ( < ) and ( > ) {but different from buttons going to next record, etc., though these two are mostly for List view layouts}, with a Tooltip saying what they are. 

 

Someone else, long ago, discovered that FileMaker can quickly move your Found Set to another instance of a table, which is NOT connected to the current one; in other words, another occurrence of the same table on the Relationship Graph, but not connected.

 

If you use Go To Related Record, started with the current table occurrence's layout, and going TO an unconnected table occurrence's layout, FileMaker will (almost instantly) move the current found set to become the found set of the other layout. It will be "saved" (for that session anyway), as no own ever goes there otherwise. These is only one "saved found set" however; though you can create another for a 2nd (table occurrence, scripts) or more, if you need to (like for another special script).

 

In the scripts below I'll call the first table "Table" and the other "Table FS" (short for Found Set).

 

Save Found Set (FS) script:

 

Freeze Window

If [ Get ( WindowMode ) = 0 ]

    Commit Records/Requests [ No dialog ]

    #

    If [ Get ( FoundCount ) > 0 ]

        Go to Related Record [ From table: “Table”; Using layout: “Table FS” (Candidate FS) ] [ Show only related records ]

        Go to Layout [ original layout ]

    End If

Else

    Beep  // so they know nothing happened, if they're in Find mode

End If

 

 

Restore Found Set (FS) script:

 

Freeze Window

If [ Get ( WindowMode ) = 0 ]

    Commit Records/Requests [ No dialog ]

    #

    Set Variable [ $layout_name; Value:Get ( LayoutName ) ]

    Go to Layout [ “Table FS” (Table FS) ]

    #

    If [ Get ( FoundCount ) < 1  // cannot use GTRR; it would not even go back to the layout ]

        Go to Layout [ original layout ]

        Exit Script [  ]

    End If

    #

    If [ IsEmpty ( Get ( ScriptParameter )) ]

        Go to Related Record [ From table: “Table FS”; Using layout: $layout_name ] [ Show only related records ]

    #

    # Or, below have a ScriptParameter; called by other scripts; need to return to other than original layout (rare)

    Else If [ Get ( ScriptParameter ) = "List" ]

        Go to Related Record [ From table: “Table FS”; Using layout: “List” (Table) ] [ Show only related records ]

    End If

Else

    Beep

End If

 

 

Notice that the "restore" is a little more complex than the "save", mostly because it has to know what layout to return to. The basic is to put the current layout into a Variable first, and go back to that. However, if you call this script from other scripts, and you want it to return to some other specified layout, you could add script steps to do instead (though I guess you could be smart, and send/get the ScriptParameter; but this is an old script)