Jump to content
View in the app

A better way to browse. Learn more.

FMForums.com

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Not sure of Window/Data Behavior in v. 7

Featured Replies

I'm not sure quite where this question belongs, but I'm putting it here because most fundamentally, this is a question about v. 7's behavior...

When I open a new window in a multi-table solution and go to a layout that is based on a different table that is related to the record on display in the first window, what happens? Does the new window display only the records related to the record on display in window 1, or does it show a different data set?

I have a multi-table solution. In this solution, I navigate (using scripts) from one table to others, opening new windows as I go deeper into the system. So, a user opens a layout displaying a Customer record, which has portals for customer payments and customer orders. The user can click on either the Payments or Orders portal, which results in a new window opening that is scripted to find and sort the records for that client. This perpetuates the behavior from FM6.

However, with 7, I thought I could get away from a mess of scripts and Finds/Sorts by building my layouts on filtered and sorted Table Occurences (TO). So instead of a script that opens a new window, finds records with the current customer ID and sorts the result by date, I would only have to go to the correct layout. A lot simpler, programmatically speaking.

My initial trials of this method have not been particularly successful. Specifically, when I open a new window, the record settings in the first window seem to be lost, and the records displayed in the second window are a "random" selection (I know there's a logic to this, it's just not mine). This is apparently due to the fact that the new window has a new context in the database, which is not based on the context of window 1.

My fallback seems either:

a) keep doing it as I have, explicitly finding and sorting the records, or,

:) building a relationship on the TO that uses a global field as a comparison, and setting that global as needed. This reduces the scripting, but does not eliminate it.

Comments or suggestions are welcome!

The Go to Related Record script step (referred to as "GTRR" in the Forums) in FMP 7 has an option to select the related records AND change layout AND open a new window, all at the same time. So much of what you want can be done in one step.

In FMP 7, always remember that a window must have a layout specified, and that layout determines what records are seen. AFAIK, a new window will initially show all the table's records, hence the GTRR step.

  • Author

Thanks. Your message clarifies the situation.

I will look into the GTRR stuff. I was actually pretty close. I'd been looking at the GTRR step in the way you suggested; I'd just failed to connect all the dots. In the past, a layout was based on the single file, and not a TO.

Frankly, it occurs to me that ultimately this feature (building layouts on TOs rather than datafiles) may prove to be one of the most revolutionary aspects of 7.

Create an account or sign in to comment

Important Information

By using this site, you agree to our Terms of Use.

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.