transfer a found set to a different already-existent window

[Glenn S.]

t

This might not be the best forum for this question; if not, feel free to move it to somewhere more appropriate.

After running a find in one window, I want to display the found set in another window using a different layout.  If I were willing to use the original window, this would be trivial: just switch to the other layout.

One approach I've considered is to set up a self-join between two occurrences of the same underlying table (matching the table's key with itself) and use Go to Related Record (henceforth GTTR) to navigate from one layout to the other.  The originating layout would display records from the first occurrent and the layout in the other window would display records from the other occurrence.  With "Show only related records" set in the GTTR, this works fine when I set the GTTR to create a new window.

But things break down when I try to use an existent destination window.  I could destroy the destination window beforehand and have the GTTR re-create it.  But that seems horribly inelegant.

Failing that, the only solution I've come up with is to add a global field to the table, use a custom function to populate it with a CR-separated list of keys for the records in the found set, and modify the self-join relation to match the table's key field against this new global field. With that setup, executing the GTTR after selecting the target window does the trick.  But this technique also is unsatisfactory.  It requires a lot of work for what should be a straightforward operation.

So my question is:  Am I missing something?  Is there a better way to accomplish this taks?

[Lee Smith]

Look at the Open New Window Script. 

https://fmhelp.filemaker.com/help/16/fmp/en/#page/FMP_Help%2Fnew-window.html

I use it all of the time.

With v17, you now have the Card Window to choose as an option.

New Window [ Style: Document ; Using layout: <Current Layout> ]

[Glenn S.]

I'm familiar with the New Window script step.  But I don't want to create a new window.  I want to use one that already exists, displaying in it the found set from a different window in which I've done a find.

[Lee Smith]

Create a second layout?

[Glenn S.]

I have.  The purpose of the second window is to display the found set from the first window using a different layout (as it happens, the first layout is set up to display in record format, and the second layout is set up to display in list form).

The problem is getting the second window to use the same found set as the first window.

This arrangement is intended for use on displays with plenty of real estate, so that both an individual record from a found set and selected data from all records in the found set can be displayed independently, and so that there can be further activity in the first (record-oriented) window without disturbing the contents of the second (list-oriented) window.

[Steve Martino]

 

11 hours ago, Glenn S. said:

I'm familiar with the New Window script step.  But I don't want to create a new window.  I want to use one that already exists, displaying in it the found set from a different window in which I've done a find.

So maybe you can save your find criteria from the first find and apply it to the window in the second find.

Otherwise your descriptions are confusing.  It would help if you used real words for your layouts, their associated table occurrences, and how they are related to each other. 

[Lee Smith]

I agree with Steve.

Maybe if we saw your file it would help us find a solution to what you are wanting.

Click the link at the bottom called Guidelines to read how to keep your confidential information safe.

See Step 8.

[bcooney]

"But things break down when I try to use an existent destination window.  I could destroy the destination window beforehand and have the GTTR re-create it.  But that seems horribly inelegant."

I never named windows...I found handling that too burdensome. Otherwise, I'd say that this is exactly how I'd approach it. I'd also leverage the summary field ListOfIds to populate the global left-hand key. I'd look for the existing window looping thru WindowNames and if found, close it. However, is that a good UX? Perhaps that second window contains a valuable found set that the user would resent losing?

Since you've already embraced a multi-window solution, why not create a new window every time?

[Glenn S.]

Apologies for the delayed reply.  It took me a while to distill the problem down into a database of its own.  I'm attaching couple files.  One is a screenshot of the full database in operation.  (It's a database of my science fiction and fantasy collection developed in fits and starts since the days of FileMaker 6.)  Notice that the "Work as List" window displays the found set from the "work" window.

The other is the distilled database.  Its View 1 layout displays trivial records along with a couple buttons to execute scripts. The "via PrimaryKey" button runs a script that tries to use Go to Related Record in a straightforward way to display the contents of the first window in a second window.  It doesn't work as desired.  The "via keyList" button runs a considerably more complicated script that works as desired to the same end.  It relies on a self-join of the PrimaryKey field to a global field containing a list the script constructs of the primary keys of the records in the found set.  It then uses GTTR to populate a layout with a portal that shows records from the other end of the self-join, but that displays the results in the "View 2" list layout.

This seems to me to be an excessive amount machinery to accomplish what's a conceptually simple task. So I wonder again: is there a more straightforward way to do it (without relying on the "new window" feature of GTTR)?

GttrTest.fmp12.zip

[GFS]

It's a long time ago, but wondering if you found a solution?  If not, then I can suggest a 4 line script, with a single additional TO.  Works well and is very fast.

[Steve Martino]

On 9/17/2022 at 4:55 PM, GFS said:

It's a long time ago, but wondering if you found a solution?  If not, then I can suggest a 4 line script, with a single additional TO.  Works well and is very fast.

Post it up.  It may help someone else.

[GFS]

18 hours ago, Steve Martino said:

Post it up.  It may help someone else.

That's true. 🙂

___________________________________________________________________

 

This is very easy and is at its easiest using a CF.  Some long-time FM users seem to think this clever lady should get the FM equivalent of a Nobel prize. 😊

You can achieve the same with a summary field or loops, but why bother, since this CF is soooo useful.  NB, it won't work for Portals, but FM's 'List' does, as it will with a summary field.

• Make a new TO (storeTO) and add a Global text field (store_g).  It doesn't need any other fields.
• Create a New Record in storeTO (it must have a record to work)
• Make a relationship between the storeTO::Global and whatever TO your window is using. (E.g. storeTO::store_g ↔ windowTO::UID)

 

To move the Found Set from one window to another:

• Set Field [ storeTO::store_g ;  CustomList ( 1 ; Get ( FoundCount ) ; "GetNthRecord ( windowTO::UID ; [n] )" )
• Select Window [ Name: "MyOtherWindow"; Current file ]
• Go to Layout [ “storeTO” (storeTO) ]
• Go to Related Record [ From table: “windowTO”; Using layout: “MyLayout” (windowTO) ]

 

I actually have a 2nd 'store' TO for storing individual windows, which creates/deletes records as windows are opened/closed.  This stores various data pertinent to each individual window, e.g. I have back/forward buttons for searching/returning to previous found.  It's really easy to do this with Agnès Barouh's clever CF.  There are plenty of alternatives to her's, but her's is non-recursive, able to deal with millions of records and generally high-fived by some FM smartypants, which is good enough for me, as an 'intermediate-level'.

 

Edited September 20, 2022 by GFS