Jump to content
Server Maintenance This Week. ×

Layout Behavior-Found sets


Steve Martino

This topic is 3143 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Hi Forum, don't know if this is the right place, but I'll give it a shot.

I wonder if this is expected behavior, regarding windows/layouts found sets.  I tried it manually after not being able to do this with scripting and it's not working.  And of course watched it through the Script Debugger.  I'll give the basics, and if someone requests more info I would be happy to oblige.

I have a layout based on a Customers Table.  I have a second layout, sub-summary report based on a related table-Interactions.

From the customers table, I click a button, perform a script that opens and sorts the sub-summary report.  I have a button on the report that omits records, changing the found set.  After I get the found set of related records, I then have another button with a script that takes that found set, transfers it to the first table, Customers.  At this point, the sub-summary report has not changed.  Then the script closes the report window, leaving me with the found set of records I found.  All of this works fine.

Now if I open the sub-summary report again, it shows all the records, which I thought it would just stick with the found set.  There is no script step that either performs a find or shows all records.

--What I tried manually--

If I go to the Customers layout, the found set is intact.  If I switch to an Interactions layout, the found set is intact-or the way I left it.

But, If I go to the Customers layout, click New Window, the found set is intact.  Then if I switch this window from the Customers layout to the Interactions layout, the layout shows all records.  What I am trying to figure out is if this is the correct behavior.  If so, I'll work around it, but I thought without any scripts or script triggers, when moving manually on layouts from one Table (TO) to a different Table (TO), the found sets remain intact. 

Any thoughts, questions, clarifications, ideas are always appreciated.

Thanks

Steve

p.s.  sorry for the long post.

Link to comment
Share on other sites

"Takes a found set and transfers it to the first table". What script steps are you using for this action?

Regardless, found sets are tied to TOs and windows.

Imagine all your layouts have a default found set (I'm not sure if that's all records, but I suspect it's the found set of that layout's TO when you last closed the file locally). So two layouts based on the same TO in the same window will have the same found set.

Opening a new window means all the layouts in that window revert back to the original defaults. Manipulating found sets and switching between layouts in that window will keep those sets but won't effect other windows or layouts based on other TOs (even if they're the same base table)

I hope that's clear enough.

Link to comment
Share on other sites

David: I suggest you test this.

Yes, changing found sets in one window has no effect on the other windows.

However, creating a series of different found sets across a series of layouts within one window, will remain the same found sets across all the layouts when you open a new window, none of them revert.

Link to comment
Share on other sites

Thanks both for your replies. 

What script steps are you using for this action?

I was just giving a brief explanation of the ultimate goal.  I'm more concerned about new windows and existing found sets.  Understanding that would then allow me to better automate the process--whether I have to do it thru a relationship, gather ID's with a loop (still in FM Pro 12) or save/restore find criteria)

I think what is happening is more in line with what David posted, but also what I see happening should be more in line with Bruce's comments, but I just don't understand if what I am seeing is correct.  Here's the part I am trying to match up with what Bruce stated, with additional comments in bold/underlined:

If I go to the Customers layout, the found set is intact.  If I switch to an Interactions layout, that found set is intact-or the way I left it.

But, If I go to the Customers layout, click New Window, the found set is intact.  Then if I switch this window from the Customers layout to the Interactions layout, the second layout shows all records, instead of the found set from the last time I left the layout  What I am trying to figure out is if this is the correct behavior.  If so, I'll work around it, but I thought without any scripts or script triggers, when moving manually on layouts from one Table (TO) to a different Table (TO), the found sets of each table, unaltered by scripts, script triggers or sorting, should remain intact. 

BTW, this is just my confusion, I don't fully understand which way it should be :)

Thanks again for taking the time to respond.

Steve 

Link to comment
Share on other sites

Bruce, I'm confident what I said in my first post is accurate but I should clarify, the found set of the TO of the *current layout* stays the same when opening a new window. However all layouts based on other TOs revert.

Keep in mind, in terms of maintaining found sets, FileMaker doesn't actually care about the layout, but rather the TO (not base table) of the layout.

Here's a 1 minute video of what I'm talking about: https://youtu.be/fES-BcJCizE

Steve's experience is a direct result of this behavior.

  • Like 1
Link to comment
Share on other sites

I was going to post a video, but had trouble.  I noticed David posted virtually the same video.  Thanks for the response, video and sample files.

So......expected behavior.  :)

 

 

Edited by Steve Martino
file wont load
Link to comment
Share on other sites

This topic is 3143 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.