Not sure how easy it'll be to explain this, since it's pretty "out there". I think I'm on the verge of something really useful for us and possibly for others, though, so I'm going to give it a shot. I'm down to a "why doesn't this work?" sort of problem, and I'm not sure if I'm just breathing my own exhaust and missing something fairly obvious, or if there's a subtle issue with FM14 here.
See the two attached files. They are essentially the same, except the "inty" file uses references from the main file (separation) while if you open the main file it's unseparated.
Each file has the following tables:
- products - just an example of a "parent" table, with just a simple name field for now
- contacts - likewise
- roles - a join table that accepts two foreign keys, "keyThis" and "keyThat". For simplicity, and to allow self-joins, in practice we'd script the creation of these records as pairs, with keyThis and keyThat "flipped" in the sister record. For the purposes of this demo, I've just left these as "one way"
- attachments - an example of a commonly used "child" table, with just a simple name field for now
- windows - (this is important) a table containing a record for each window "instance" of the user's "session" (in practice, we'd get a session key from a new session table on startup, but just to keep things simple, I'm declaring a variable on startup for now).
Here's what I'd like to accomplish:
Our solutions tend to have a lot of many-to-many relationships. For example, an attached file might be linked to 0:M contacts, 0:M activities, 0:M objectives, 0:M products, and so on. Other examples from our current base include custom attributes, activities, objectives and more. (For this demo, I'm talking about "parent" and "child" for clarity, but in reality a table often exists in both roles.)
In the spirit of "selector-connector", I'd like to be able to have, say, a portal of attachments via the roles table on contacts, and be able to copy/paste that portal to products, activities, objectives, etc. without repointing everything. Selector-connector as defined now would allow us to do this, but only if we give up multiple windows, which we find useful for a variety of reasons, and which is kind of a key feature of our base solution and other development methods. (Not trying to reopen that debate here; we know we could give up multiple windows and get what we want. We're going to try everything we can to get the advantages of both, though.)
Some moving parts:
The window title would include a window "instance". For this demo, it's a certain number of BOM characters (char 65279, an invisible character with no width). The first window you open would be instance 1, and if you spawned a new window it'd be instance 2, etc. In our current solutions, we put the window instance in brackets at the end of the window title, but I like that the BOM character method doesn't mess with the readability of the window title.
Each table would have an unstored calculated value that is the window instance (determined by the current window name) and the session key. On record load, a script would set the primary key of the main record into a field in the windows record for this instance and session.
Here's what I'm seeing, and trying to understand:
I've got the main, non-separated file set up as a proof of concept, and it works find in FMP13 and FMP14 (although there are plenty of refinements and continued testing to do, it's a decent "proof of concept".)
The "inty" file, with separation, seems to work well in FM13.
However, the inty file doesn't work right in FM14. OnRecordLoad, even though the unstored calc for windowInstance exists in the local (contacts, for instance) table, and a windows record exists for that same instance, FM can't "see" the windows record unless and until it creates one via relationship. Instead of setting the current key into the existing windows record, a new windows record is created, and the old windows record (with a different keyCurrent) ends up getting recognized, so I end up seeing attachments from this record and a previous record (or records) that I viewed in this window.
Why I think this is worth the trouble
Currently, our base solution includes a handful of these "applicable everywhere" types of supporting records: attachments, activities, related contacts, custom attributes and objectives. I actually have a lot of ideas for more of these, for example a "comments" table that would work somewhat like posts here on the forum, so I could, for instance, follow and comment on other users' comments regarding a specific project, contact, etc.
We currently don't spread these around to all data elements even though they are applicable at least in theory to just about anything. The reason is that currently we end up with a flock of required TO's in each TOG, for each portal. Also, if we make improvements to one of these "applicable everywhere" tables/portals, we need to go around setting and re-pointing things on each layout. If we could copy/paste whole tabs/portals, we'd use these utilities in more places, update them more consistently, and generally get more out of them.
I absolutely love the idea of selector-connector, for reducing TO proliferation and making these things more portable, but having to do away with multiple windows is a tough choice. Being able to spawn a new window (for example, if the phone rings and you want to record details of the phone call) without abandoning what you were working on, and just generally being able to look at two things side-by-side, is a feature that's been a strong selling point, and one that we've pushed hard with existing clients. Giving that up, while it may eventually prove to be an "either-or" proposition, is not something we'd take lightly, and frankly feels like a big step backwards.
I know there are other considerations with this idea, such as keeping the number of windows records reasonably low (deleting old ones). I also know that there are other ways we could pursue our goals. I'd ask that we not debate the merits of multiple windows, whether repointing things on layouts is "really so hard" and things like that. I'm not closed to those discussions, but I'd like to focus on what's changed in FMP14 that makes this approach not work. I've spent quite a bit of time and effort trying to get this down to where I can see the moment that it breaks in FMP14 with separation, but I just don't understand what I'm seeing. I'd like to focus on understanding, and possibly working around, the one issue I've narrowed down here.
I suspect that even with the demo files and the length of this post, I've not covered all the moving parts in enough detail, or defined the goal clearly enough. If you're willing to help me work through this, though, I'm more than willing to answer questions you may have.