Found sets and new windows

[bluearrow]

Hi,

I must be missing something, cause I do not understand the way my searches are working.

I have a scripted search. The search opens a new window using a search TO, related to the source TO by a cartesian relationship. If the search finds records, I use a GTRR step, From table: (search table) Using layout (the original layout). I then close the search window and the original window. This leaves the user with the result window and the result records. This works fine.

Here is my problem:

If I start a new search in another TO (using exactly the same method) and the search finds results, the new window shows me the results, but I loose the results of the previous search. FM shows all records for the fisrt TO, and the results of the second search.

The navigation is also scripted, the user moves from one TO to the other pressing a button that just Go to layout (nothing else). Maybe is something I do not understand, but I am expecting to keep the found results of the first TO, and the second TO (and any other TO, by the way) in the new window, thus allowing the user to flip from one TO (layout) to the other and see both search results. Only if a new search is carried out in any of those TOs, should FM show a different found set in that TO.

What is wrong? can this be done? how?

Thank you

[bluearrow]

OK, I found the answer myself.

It is a little bit complicated because there is no logic behind it, but the intrinsec behaviour of FileMaker.

This has probably been said somewhere else, but I mention it just in case it helps somebody else.

- A new window based on the same layout as the active window will only keep the foundset of the active layout. All other founsets will be lost.

- Layouts based on the same TO have the same FoundSet.

- Layouts based on different TOs keep their own foundsets.

I have finally build a scripted Find system that allows me to keep foundsets, but I had to use the GetNthRecord function instead of laoyuts or windows combinations. The function gathers the founset IDs and keep them safe, restoring them when is needed. I have read that this method is slower that one based on the TOs behaviour described above, but so far it is the only way forward I have found.

Cheers

[Fenton]

Each window has its own found set. It will not lose it unless you change it. But keeping a bunch of windows open in order to save found sets is awkward. There is another fairly simple and fast way to save a found set. You would need a separate TO (disconnected) of the table, for each found set you'd want to store. I only use it to save the current found set.

Each Table Occurrence Group (TOG) keeps its own found set. You alluded to this by saying "different TOs", but, since you'd seldom have 2 layouts for the same table in the same TO, it's actually different TOGs.

There is a trick to saving a found set in a different TO (of the same table) in a different TOG. I didn't come up with it, but I'll try and explain it (from something I wrote earlier)

Each Table Occurrence Group (TOG) maintains its own found set. You can transfer a found set from a TO in one to a TO of the same base table in another by using Go To Related Record [], with the relationship being the ONE YOU'RE ON (strange but true), and specifying the Layout of the unconnected one. Then you come back to your original layout and continue processing. This effectively transfers your current found set to the unconnected one, where it is "stored", unaffected by changes to the found set in your current one.

We actually use this ability sometimes without really noticing. We use Go To Related Record, and specify a layout which is in another TOG, not connected to our current layout. FileMaker shows the resulting found set of our relationship.

To Restore the found set you just do the opposite. Go to the layout of the stand-alone TO. Then Go To Related Record using ITS OWN TO, and specify our original layout. It transfers the saved found set back to our original layout.

[bluearrow]

There is a trick to saving a found set ...

Yes, I tried the trick before deciding to use the GetNthRecord function. It works fine and is very, very fast transfering/keeping one foundset in one window, but it useless in other (more complex) situations. It only keeps one foundset, the foundset of the TO you were coming from. But what about keeping several foundsets at the time in a new window?

Imagine you have a layout with a MENU bar (FilleMaker buttons for navigating to layout1-TO1, layout2-TO2, layout3TO3, layout4-TO4). The user has already carried out a search in TO1. Therefore, there is a foundset for TO1. There is also a foundset for TO2, and TO3. He is in layout4-TO4. He should be able to jump to TO1, TO2, and TO3 and find the same foundset he left in the last find. The user is not carrying out a search, but coming back to the TO and he expects to find the same set of records he left the last time he visited that TO.

This is possible if you do not open a new window. However, if the user wants to carry out a new search from layout4-TO4 (or any other, by the way)the method you describe only keeps the foundset of the TO the user is coming from. All other foundsets are lost. Remember I am scripting the search, opening a new window and showing the results in a new window (and/or closing the window and returning to the original one if the user cancels the search or the search returns no records).

By keeping a global for each TO with the result of the GetNthrecord, and stablishing a relationship based on this global and the source TO Id, I am able to keep the foundsets, no matter what window I open or close, neither matters the results of the search (of course, if there are search results, then I fill in the corresponding global using the GetNthrecord function...).

I see no way to do this using the trick you mention. As I said, it is a nice and elegant trick, but in this case it is not the solution.

Regards

[bluearrow]

...It will not lose it unless you change it. But keeping a bunch of windows open in order to save found sets is awkward.

Ahh, I forget to clarify this. I am not keeping several windows open. Only 2 (the original one and the one to search), and only while the user carries out the Find. Once the search is over, only one window remains, showing either the result of the search, or the previous foundset of the source TO. My problem was that I also wanted to keep all other foundsets, for any other TO available to search. I have solved it now.

I agree with you that keeping several windows is awkward... and a lot of work :badidea:

[Søren Dyhr]

I am not keeping several windows open

Yikes no! This is how it goes:

http://www.sumware.net/robfm/savingfoundsets.php

So it's more a number of unnattached TOG's ....

--sd