Steve Martino Posted September 15, 2015 Posted September 15, 2015 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.
David Jondreau Posted September 16, 2015 Posted September 16, 2015 "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.
bruceR Posted September 17, 2015 Posted September 17, 2015 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.
Steve Martino Posted September 17, 2015 Author Posted September 17, 2015 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
bruceR Posted September 17, 2015 Posted September 17, 2015 Since nobody observes what you observe, it would be interesting if you can produce an example file that displays this behavior.
David Jondreau Posted September 17, 2015 Posted September 17, 2015 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. 1
bruceR Posted September 17, 2015 Posted September 17, 2015 Dave and Steve: you're right! I made a simple example file to demonstrate this. WindowTest.fmp12.zip 1
Steve Martino Posted September 17, 2015 Author Posted September 17, 2015 (edited) 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 September 17, 2015 by Steve Martino file wont load
Recommended Posts
This topic is 3353 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 accountSign in
Already have an account? Sign in here.
Sign In Now