This looks marvelously interesting, Mike! I'll check it out today and circle back; thank you!
I just thought I'd circle back to thank you for your kind referral to the above-referenced article on cartisian joins. The issue is resolved, and the layout is currently updating very rapidly across both Filemaker and Filemaker Go users. Thank you!!!
Awesome, make sure to bookmark weetbicks, I think every post they've ever made has helped me as a developer.
I wonder whether you (or anyone other kind readrs) can offer any advice as to a snag that I encountered with this.
I discovered today that when the user is scrolling through her portal of calls, if her secretary (while on another layout for the same record) triggers the portal to refresh in a way that requires the records appear in a different sort order, then that sort function won't occur until the user has de-activated her portal.
Funnily enough, changes to the field are made immediately apparent to the user with no problem. It just seems as if the sort order won't refresh so long as the user is actively scrolling through the portal, or even scrolls through it once and then leaves the mouse pointer hovered over the portal.
Any idea how to get around this?
How is the portal sorted? Via the relationship? Or via the portal itself? That might have something to do with it.
I'm not terribly familiar with record locking behaviors inside of portals off the top of my head. There is also the possibility that weetbick's method is not entirely foolproof.
I thought I'd circle back to let you know how this worked out...
It looks like the weetbick method isn't foolproof. The problem with it is that so long as a user has made the portal active, that portal won't refresh to reflect changes made by other users for the entire duration the portal is made active.
This "dead" state that exists while the portal is active occurs even where the user merely hovers over the portal and scrolls up and down via the mousewheel, then walks away from his desk with the pointer left hovering over the portal; even under these common circumstances the portal won't refresh until the user comes back to his desk and clicks outside the portal. The problem here is that users I'm working with don't want to have to remember to click outside of the portal after scrolling up and down through it or otherwise making it active. They want to rest assured that their live data is being pushed to them at all times.
I actually engaged a top developer to solve the problem. What the developer did was use an Install OnTimer script that loops the refresh of the portal by way of setting the trigger field for the cartesian join every 2 seconds. The refresh loop is triggered when the user enters the layout, and halts only if the user puts a portal row in focus by clicking in it, as the presumption is that the users don't want the loop function to bump them out of a record they're reviewing or editing. When the user is done reviewing/editing the record, he now hits a "Save" button in the portal row; the "Save" function is illusory, and merely functions to resume the refresh loop, but because the button is marked "Save," it feels more natural to the users to effect than having to remember to click outside of the portal to refresh it.
It's a complicated but reliable and admirable solution by the developer, and so far works like a charm. Thanks so much for pointing me in the right direction!!!