Layouts: A Context Question

[T-Square]

I wanted to call this a question of ontology, but figured that wouldn't get much attention...

As I understand it, FM7 uses the context of a table occurrence to determine the recordset to view in a given layout. However, it is not clear to me what happens to the context when a user or script changes the layout in the window.

Specifically, if I am viewing a client record in my database window, and I click on a button that changes the layout to view the client's invoice records in the ClientInvoices layout--a layout that is based on a TO that is linked to the original client TO--how does FM respond? The ClientInvoices TO is supposed to be based on a link by client ID to the clients table, but suddenly there's no client instance in memory. So, which records will display?

My initial experience is... all of them in the table.

Maybe I'm just missing something?

David

[SlimJim]

Working on the assumption that your button simply changes to another layout then I think that in general you would expect to see all the records in the underlying table of the TO attached to the layout. The ClientInvoices TO may be defined in order to set up a link to your clients table but as a TO it is simply another name for the underlying table and unless the relationship is built into your navigation I don't think you should expect anything other than the full set of records to show.

If, however, your button includes a go to related record step, display in the other layout and only display related records then the client ID link should be maintained as presumably the set of records "found" by the relationship will be the ones to show.

[comment]

Each TO has its own found set and current record, much like a window.

[T-Square]

Comment, I think SlimJim's surmise is correct; it's what I'm observing at any rate.

The correct answer here, I believe, is:

D) If you want to show a subset of records in a related table, you need to use the GTRR command, whether you change layouts or open a new window. The mere fact that a TO is defined to use a limiting relationship does not limit the recordset. There's a logic to this, but it isn't exactly obvious...

David

[comment]

I'm afraid not. I don't know what you're observing, but the test is simple: create two TO's of the same table. Create two layouts, one for each TO. Go to one layout, omit some records. Select a record. Go to the other layout, omit some (other) records. Select another record. Now toggle between layouts.

GTRR is another thing, since it explicitly SELECTS a record, AND (if the option is selected) CREATES A FOUND SET.

Since GTRR lets you go to a TO using a layout of another TO of the same table, I have not yet found a reason to have a layout based on a TO other that the "main" TO of the table. But it depends on how you build your graph - in some configurations, you might need a layout based on another TO just to place a portal.

[T-Square]

Comment--

I think you're not understanding my situation quite.

Here's my scene:

I have a Client window with a portal that displays related services in brief. Next to this portal is a button that:

1) Hides the current window (it is still in memory)

2) Opens a new window

3) Goes to the Services History layout and

4) Displays the client's service history.

In the old world way, I set a global to the ClientID, went to my new window and searched for it, and then sorted the result. Clunky but reliable.

If I change the Services History layout to be based on the ClientServices TO, which is bound into the relationship graph by a link from Clients::ClientID to Services::ClientID, then the entire 100k recordset is returned. Moreover, if I define the relationship as being sorted, then the entire 100k records are sorted (or try to be, I cancelled out when I figured it would take 3 days to update).

Your example is different. Although you don't outline what I'd see in each of the two layouts you describe, I imagine you're seeing that each window has its own active recordset. In your example, you're manually filtering, and each window has its own recordset preserved; in mine, I've been assuming that the filter would be applied by default, based on the value in the previous layout.

I'm working with a sequential opening of windows, the dataset of the second being dependent on the content in the first. In my mind, the fact that I am opening a layout whose content in the relationship graph is based on the value in an open window should be enough for FM to determine the filtered recordset to display in the new window.

I guess I come up with that interpretation because FM docs talk about the context of a TO affecting the recordset that gets seen. I took that to mean on a global basis, but really, it only applies from within the confines of a particular layout. And if I think about it, that makes sense.

Cheers,

David

[comment]

I think you're not understanding my situation quite.

Probably not - your last message certainly went way above my head...

I was NOT talking about two windows. I was talking about switching layouts in the same window. If you ONLY SWITCH layouts, you will see that each layout (more precisely, each TO) keeps its own found set and current record.

The found set in each TO is ENTIRELY AUTONOMOUS: a TO does NOT "know" it is related. A relationship alone does not create a found set - it is only when you use GTRR that the found set changes.

Moreover, a single TO can be related to more than one other TO's, each one dictating another found set, and possibly another sort order. How would the poor TO decide which master to obey?

SlimJim is correct in one aspect: when you switch to a layout of a different TO, you will, AT FIRST, see all records. Why? Because you have not yet omitted any...

[T-Square]

Methinks we're now all barking up the same tree. You have to establish a recordset in a layout, by finding, GTRRing (can that be a verb?), omitting, etc.

So now I want to know, how long does FM remember that found set? Does it reset when you close the app? Under what circumstances does it carry over, and when does it reset?

[comment]

I believe all TO's are created equal, so I would expect whatever holds true for a flat file to be equally true for any TO. Should be quite easy to test, though.

[SurferNate]

I believe FM resets the found set to ALL for every TO every time you restart the app. If you close a TO layout and there are no other layuots open with that source TO I think it resets the found set to ALL. Further, if you open two windows, each based upon the same TO, and perform two different finds, you will have two different found sets. I believe FM by default carries a found set from a parent window to a child window, or if you manually open a new window containing the same source TO.

1) If you have the same TO in two windows you can have two different found sets.

2) If, from a parent window, you create a new child window with a different source TO, you need to generate a new found set for the child window.

Please correct me if I am mistaken, this is my experience only.