Jump to content

Glenn S.

  • Posts

  • Joined

  • Last visited

FileMaker Experience

  • Skill Level
  • FM Application
    15 Advanced

Platform Environment

  • OS Platform
  • OS Version
    High Sierra

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Glenn S.'s Achievements


Apprentice (3/14)

  • First Post
  • Collaborator
  • Conversation Starter
  • Week One Done
  • One Month Later

Recent Badges



  1. 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
  2. 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.
  3. 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.
  4. 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?
  5. 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.
  6. 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
  7. 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.
  8. 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?
  9. (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?
  10. I've submitted a bug report. Thanks for everyone's help in diagnosing the problem. (Is there any way to get visibility into FileMaker's bug tracking system to see what they're doing in response to a given bug report?)
  11. Yes, it's behaving as it should for you. If we could try Mac+9.0.2 and Windows+9.0.3, that would help narrow down possibilities for the problem's cause. If anyone could try either of those combinations (unfortunately, I can't), I'd appreciate hearing the results.
  12. I've attached a clone of the database to this reply. (The clone suffices to demonstrate the problem and the whole thing is too large to post.) When you run it, bring up the Help menu and note the dimmed item. That's the one in question. [The database is something I started several years ago to keep track of my fantasy and science fiction collection. It tends to be in a continual state of flux as I learn better ways of doing things in FMP and rework it to match.] [tab]--Glenn Authors_and_Works_Clone.zip
  13. I'm using FMP9's custom menus -- no plugins. I'm using the admin account, with all privileges enabled, so it's not a permission problem. I'm at version 9.0v3, and when I check, the program reports that no updates are available. [tab]-- Glenn
  14. In one of my databases I added an item to the Help menu that brings up a submenu of help topics specific to that database. This custom menu item works fine when I bring the database up in FMP8A. But when I run it under FMP9A, the menu item is dimmed. I've examined the settings for my custom menu set, for my replacement for the standard Help menu, and for the item I added in my replacement and can't find anything that might explain the difference in behavior. Does anyone have any ideas of what might be going on? Have I stumbled over a regression from FileMaker 8 to FileMaker 9? -- Glenn
  • Create New...

Important Information

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