AnsweredAssumed Answered

Xpost: Since the update portal refresh not working

Question asked by StanMillar on Apr 9, 2014
Latest reply on Apr 10, 2014 by StanMillar


Xpost: Since the update portal refresh not working


FileMaker Pro


Advanced 13.0 v2 Updater: FMP13.0.2.22

Operating system version

OSX 10.9.2

Description of the issue

I have a menuing system that operates as follows:

Click on a menu item in a portal which runs a script:

Go to a developer layout attached to the Menu TO
determine if the menu item clicked has sub-menu items
If it has, change the arrow displayed beside the menu item clicked (gives the same effect as clicking on a folder in the Finder)
load up the sub menu IDs into fields so that they display in the menu portal on the original (home) layout and some other housekeeping
return to the home layout where the arrow has changed to the new graphic (pointing down) and the top level menus and the sub menus from the one clicked are displayed. Well - no.

All this has worked perfectly for years.

Since the upgrade, the script runs, the arrows change BUT the sub menus refuse to display. On the developer layout, I can see that things have changed to add the sub menu IDs into the correct fields for display.

If I manually navigate to the developer layout from the home layout and then immediately return to the home layout - there they are - displayed in all their glory!

I have tried:
add refresh window after returning to the home layout. No change.
add commit record both before and after returning to the home layout. No change.
add steps to navigate to the home layout, back to the developer layout and back to the home layout . No change.

If I open the file in FM12 Advanced, everything works.

Seems like something has changed since the update. I hate to say the "b"(ug) word but nothing else has changed.

The menu portal on the home layout shows the menu records via a multi-predicate relationship. In all cases, the top level menus continue to display. This is the correct behaviour as their IDs are listed in the foreign key field.

The opposite effect occurs if the user (me) clicks to "close" a menu. The arrow changes, as it should, but the sub-menus continue to display. I can verify that their IDs are removed from the foreign key field.

Refresh Object script step after a commit with flush cache.

Added a new portal to the home layout showing the menu name field and the fk field then manually copied the IDs into the fk field in this portal. This worked. The menus showed up in the menu portal.

New wrinkle.

The sub menus (the correct ones for that top level menu) show up in the menu portal only _after_ the top level menu is "closed" and their IDs are _removed_ from the fk field by the script!! At this stage in the process, they are _not_ related.

There is something very strange going on here. To say the least.

I added a fresh instance of the menu portal to the home layout. The result is the same so it is not a problem with the original portal.

Expected result

portal records update

Actual result

portal records do not update

Exact text of any error message(s) that appear




If I open the developer layout in a separate, hidden, window, all the problems go away without any pauses in the script.

How this differs in refreshing the window from using the script step, I don't know, but at least it works.