GTRR problem

[sandyinlet]

To provide a non-confusing Search routine I'm opening a new window which floats above the current layout the user is using. This floating window is blocked from closing until the user clicks either of its Cancel or Done buttons.

The user sees the context, sets their criteria, executes the search within the floating window and if they click the Done button the current set of records should be transferred to the window below, and then the floating window closes. (A click on Cancel simply closes the floating window.)

Here's the problem — transferring the found set in the floating window over to the window below. Elsewhere in this solution I've been using a layout dedicated to temporarily save the current set of records and then restoring that set as needed, such as in cancelled searches. This works fine until a floating window enters the equation.

Here's the observed sequence. The user clicks the Done button on the floating window.

Go to Related Record [show only related records; From table: "COMPANIES"; Using Layout: "Companies|SaveSet" (COMPANIES.SaveSet)]

(I can visually see the desired set of records turning up on the layout "Companies|SaveSet.")

Go to Layout [original layout] (which restores the original content in the floating window).

Close Window [Current Window]. (The floating window closes.)

Which puts the user back on the layout they were working on when they initiated the floating window. However, simultaneously with the close of the floating window the layout Companies|SaveSet reverts back to its original set of records. Therefore I'm unable to use a scripted Companies.RestoreSet routine.

Is there something simpler available to simply move the current set of records from the floating window to the window below? What am I missing?

[IdealData]

Try naming the windows and reference them in your script using the names you allocate. The you can specify the window you want to close at the end.

Also the "last layout" may be confusing due to the GTRR.

[comment]

with the close of the floating window the layout Companies|SaveSet reverts back to its original set of records.

No, that's not what actually happens. A found set is a property of the window, not (just) the layout. The original window in the background doesn't revert back to its found set - it keeps its found set unchanged throughout the entire process going on in the other window.

A simple solution would be to let the user enter the criteria, close the (new) window and perform the search in the original window.

[LaRetta]

... or close the original window and just rename the new window to the old one (switching to the original layout if necessary). When a User chooses to 'keep' a found set, I do this quite often. If they don't want to keep it, they can just close the new window and be on their prior found set.

[sandyinlet]

No, that's not what actually happens. A found set is a property of the window, not (just) the layout. The original window in the background doesn't revert back to its found set - it keeps its found set unchanged throughout the entire process going on in the other window.

That's odd and counter to my experience. I have a second Search routine that doesn't involve a second window. But it does start with a preliminary save to a layout using the TO "Companies.SaveSet." That TO is isolated, has no relationships going in or coming out.

When the user does a find that comes up empty, instead of dumping them or showing all records I run a script that restores exactly the same set of records and jumps back to the same record in the set. To do that it utilizes the set of records on the Companies|SaveSet layout.

Note this: when I jump back and forth between the two layouts, the regular working layout and the Companies|SaveSet layout, I see two distinctly different sets of records. It's because the original set of records got stored in Companies|SaveSet that I was able to return that set to the working layout.

But you're onto something. Involving a second window has an effect I don't want. (I just had a thought while writing this. If it works, I'll post it here.)

A simple solution would be to let the user enter the criteria, close the (new) window and perform the search in the original window.

I don't want to do that. Why? Because I'm letting users fine tune their selection. I'm supplying an Omit button to hide individual records. And I'm instructing users to use an = sign to find records with empty content, then use an Invert button to reverse the polarity and display the hidden records.

[sandyinlet]

Yes, problem solved. Save all the co-ordinates for the current window before initiating the floating window. Then when the user confirms their search, make the floating window become the underlying window in exact location and window name. Then close the window the user started with — no longer needed and potentially confusing to the user.

Definitely counter intuitive. But it works without a blink.

[LaRetta]

Indeed counter-intuitive! But the entire process (after storing the original window name as variable and prior to restoring the window name based upon the variable) can be a separate script which fires and is used for all instances when you want to replace an existing window. It is seemless to the User and is actually easy to implement and I suspect is what Ideal Data was suggesting. BTW, I think you might have misunderstood Comment; he knows that each window produces an independent found set. But overall, your problem is solved and that is wonderful!

Happy New Year to you! :laugh2:

[comment]

I run a script that restores exactly the same set of records and jumps back to the same record in the set.

There's no contradiction here. A window has more than one found set - it has a found set (and current record, etc.) for each TO (that has a layout*). But when you open a new window, it inherits only the current TO's found set.

I don't know of a simple way to transfer a found set to an EXISTING window (it's too bad GTRR doesn't include such option). But it's possible to store the found set's IDs in a global field, return to the original window and use a relationship based on the global to restore the found set there.

---

(*) Some sources refer to a "found set for each TOG", and stress the importance of not having a relationship between the two TO's when doing the save/restore found set trick, but I believe that's an unnecessary precaution.

[sandyinlet]

First, my thanks to all who have contributed to this thread and to my growing understanding of this current FMP environment. It's through bumping up against unexpected walls and then being lead to look at things differently a whole new world opens up.

I don't know of a simple way to transfer a found set to an EXISTING window (it's too bad GTRR doesn't include such option). But it's possible to store the found set's IDs in a global field, return to the original window and use a relationship based on the global to restore the found set there.

Storing a found set's IDs in a global field sounds suspiciously like a trick I used in FMP6 days. However, if I remember correctly, that one had a limit of how many records could be stored that way, and therefore not safe to let out into the wild all that frequently.

Question: Are there similar limits in FMP9? I can anticipate places I might want to employ that technique. Rob Russell suggests, "For saving found sets long term… you still need to build up a 'stacked' set of record keys, which can be very slow on large found sets." Comments?

All the best in this new year.

[comment]

That limit is now at 1 billion characters per field (text). As for building the set, I believe the fastest method is to use Copy All Records in a layout that contains only the ID. The limit here is available memory. For other methods, see:

http://fmforums.com/forum/showtopic.php?tid/197149/

I am still puzzled why you need to open a new window in the first place, if your original found set is saved in another TO.

[sandyinlet]

I am still puzzled why you need to open a new window in the first place, if your original found set is saved in another TO.

Primarily user interface related. Yes, I could easily switch the user to a different layout within the same window. But by presenting them with a floating window within which to set their search criteria, the user maintains visual contact with where they've come from and where they are returning to once the search is performed. It's all about keeping users comfortable, particularly sales execs who have minimal patience with computers and regard them as having minds of their own.

[bcooney]

I realize that you like the i/f of a floating window, but I had posted my Find script a while back, and thought you might want to check it out. Link

[comment]

I can understand a new window for entering the search criteria. But as a user I would expect the results to be displayed back where my previous found set was.

[LaRetta]

I can understand a new window for entering the search criteria. But as a user I would expect the results to be displayed back where my previous found set was.

The current window will BE the previous found set. I am unsure why this point seems to be missed. I assume it is because *I* am missing something then. A new found set, replacing the original once okay'd is quite logical to me. The new window of that found set, replacing the original is also logical.

But something says I'm missing your point, Michael. Can you fill in that gap for me? Because renaming a found set to the prior window is very simple indeed. And I've used it many times quite successfully. But yet I trust your perceptions even more.

[comment]

I am not saying your method won't work - just wondering what advantages it has. I imagine a large window holding the found set, and a small window to enter the criteria. So far so good, but when I say OK to the criteria, I expect to see the results back in the large window. If there's any fiddling to be done directly in the found set, like omitting individual records, it should be done there, IMHO.

I am trying to think of another application with UI similar to what you describe, but I cannot come up with one.

[LaRetta]

I imagine a large window holding the found set, and a small window to enter the criteria. So far so good, but when I say OK to the criteria, I expect to see the results back in the large window.

Exactly what happens. As for the User perspective, they see nothing except when they close the small window, their new found set appears in the original window instead of their prior found set. And additional omits DO take place in that new found set back in the original window.

I believe that there is LESS fiddling than any other method I've tried or read about. If you wish, I can provide a demo later. It is a technique I learned here on Forums (not sure who from, unfortunately) but I'm hooked on the method. :wink2:

[comment]

Exactly what happens.

That's not what Sandy said (or I misunderstood what Sandy said). But with regard to THIS arrangement, I am still puzzled why:

1. Open a new window

2. Enter criteria

3. Perform Find

4. Close the original window

5. Rename and reposition new window to mimic the original window

is simpler than:

1. Open a new window

2. Enter criteria

3. Close the new window

4. Perform Find

----

EDIT:

Oh, I get it - you're letting users into Find mode in the new window. OK, that's another matter. It's too bad Copy All Records doesn't work with find requests.

Edited January 2, 2009 by Guest

[Stat Larry]

I think there MIGHT be some information associated with the ORIGINAL window that might still be desirably preserved... And which has NOT been addressed in this thread YET.

The original window not only preserves a "found set" for the current layout, but also for OTHER layouts/table occurrences that have already been worked with, right? (Check me on this... please!)

So when you create a NEW window to execute the find, and then later rename/resize that new window to LOOK like the original window... you also lose that information on the found sets that were saved "behind the scenes" in the original window.

That might be OK, or it might be undesirable - depends on your specific situation. But that WOULD be one of the side effects of the approach that renames/resizes/repositions the NEW window to give the user a perception it is the same window they started in.

I'd love for folks here to either confirm whether I've understood this side effect correctly... Comments please?

[comment]

Yes, that is correct: a new window inherits the found set of the current TO only.

[sandyinlet]

I think there MIGHT be some information associated with the ORIGINAL window that might still be desirably preserved... And which has NOT been addressed in this thread YET.

The original window not only preserves a "found set" for the current layout, but also for OTHER layouts/table occurrences that have already been worked with, right? (Check me on this... please!)

So when you create a NEW window to execute the find, and then later rename/resize that new window to LOOK like the original window... you also lose that information on the found sets that were saved "behind the scenes" in the original window.

That might be OK, or it might be undesirable - depends on your specific situation. But that WOULD be one of the side effects of the approach that renames/resizes/repositions the NEW window to give the user a perception it is the same window they started in.

I'd love for folks here to either confirm whether I've understood this side effect correctly... Comments please?

Hi Stat Larry

I'm the original poster that began this thread. Yes, all of what you surmise is true. Wasn't/isn't a problem for me because the new window is to perform a find. By closing the window the user is in fact choosing a new found set.

The best I remember the situation (it's been a few weeks) the problem only arose because I had produced a new found set and was trying to move that set to the main window, and that's when the problem arose. I'm currently doing a bunch of things with secondary windows. They have never been a problem — except in this single instance.

If you want to preserve the found set in the original underlying window before closing it, there's a technique I learned from John Mark Osborne. If you need it (not complex but it needs a bit of explaining), send me an eMail to .