copy found set to existent window?

[Glenn S.]

(Not sure if this is the most appropriate sub-forum for this question. If not, please suggest a better one and we can move the discussion there.)

Can anyone suggest a technique for transferring a found set from one window to another, already existent, window?

I know that one can use the New Window script set to create a window whose found set is the same as the one active when the script is executed, and I know about using Go To Related Record to show related records in the same window or a new window. But the missing piece is showing the records in a distinct, but already existent window.

I'm using a workaround that first destroys the target window and then recreates it, but that causes flashing that I'd rather avoid.

Any ideas?

[lolmeister]

I'm no pro but shouldn't "Choose window" work?

[Glenn S.]

Could you elaborate? There's no "Choose Window" script step, so I'm perplexed. Are you referring to an option for some other script step?

[lolmeister]

I'm sorry, I have FileMaker set to Swedish, so I'm not sure what it's called in English. Perhaps "Select window"?

[Fenton]

I think he meant "Select Window," but that's not going to transfer the found set. If you could possibly recreate the found set via a relationship using a global field, then that would work. This works best if there is an ID you can use (ex. Invoice_ID, etc.). Otherwise if it's just whatever found set, you could use Copy All Records, or a Loop, or a Custom Function to capture all the serial IDs of the current records, gather them into a multi-line global field (text), then use that to recreate the found set.* But each window (as you've discovered) keeps its own found sets.

I tried to use the "capture the found set using a separate TOG," but it doesn't work either, because each window keeps its own found set :-|

*Of course, if a large found set, then this is going to take longer, and be as much or more annoying than the window flash.

Edited April 12, 2008 by Guest

[Glenn S.]

Thanks for the suggestions.

In some situations, the found set I want to copy is defined by a relationship, but in others it's arbitrary (resulting from an ad hoc find command). In the database where I want to do the copy, the found set could grow to include 5000 records or so, but more typically it will be in the range of a handful to about a hundred. (But I'm interested in techniques that apply generally, not necessarily just to this database.)

I haven't used multi-line keys yet in my FileMaker adventures, so this will be a learning experience for me. I'll check back in after I've done some experimentation and report on how it went for me.

[Fenton]

Basically, unless you can use a known relationship, which can be recreated via a global, I think you will be better off putting up with the flash of a new window. Recreating a found set of thousands can be done, but will create a noticeable lag. Hundreds, hmm? Hard to say. Always test such on a network however, to see what the speed really will be for the users.

[Dick in Singapore]

To get around that problem, and for other benefits, I create a field User_Flag_t. (Minimally indexed) Then in window 1 I set all the current found records with an "X" in that field, go to the 2nd window and do a Find for User_Flag_t = "X". My DB has about 60k records, and it Finds in one second.

Alternatively, you could have a portal in the 2nd window that uses Global_Flag_g set to "X" in a relationship to User_Flag_t. Then you don't have to do a Find - the portal does it for you.

I use that feature so much that I have a utility script that sets the "X". Either toggle this record's value, or flag all the found set, or clear the found set, or clear all -- depending on the script parameter. Then a button collection to trigger each of those options.

[Glenn S.]

I'm still working on the original problem of transferring a found set to an existent window, but am running into detours on the way.

I started investigating using a global multi-line text field as a key for one side of a relationship that matches primary key values of records on the relationship's other side. I set the relationship up as a self-join (adding the global match field to the table that I want to select records from).

But when I set up a portal displaying records from the table occurrence on the other side of the relationship, the portal display all records from the table, regardless of what I set the global match field to. This indicates that the relationship isn't relating only records whose keys equal one of the values in the multi-line match field, as I expected it would.

I suspect I'm missing a rather basic point here, but can't figure out what it is. Can anybody set me straight?

I've attached a database that's stripped down to essentials, but illustrates the problem.

Self_Join_Test.zip

[Fenton]

You need to switch the 2 fields in the relationship. The unstored global field should be on the "originating" side of the relationship, i.e., the same table occurrence as the layout itself. An unstored field does not work properly as the "target" of a relationship (except for one using the X Cartesian operator, which matches all records, no matter what).

Self_Join_fej.fp7.zip

[Glenn S.]

Thanks! I guess I got blinded by all the statements I've seen that say that relationships are bidirectional and can be traversed in both directions, and didn't notice any qualifiers that might have been present.