On what relationship have you based this portal?
What method are you using to get the portal to refresh after each keystroke?
If you are using Refresh Window [flush cached join results], don't use that method.
This may be completely separate from the script that opens the window. What method do you use to pop open that window and display a record?
My demo file was developed in windows and does not show this lag, but I haven't tested it extensively in FMP 12--so we may have an undiscovered issue with this method here. My demo file no longer uses Refresh Window[flush.. to update the portal but the original version does.
OnObjectModify script trigger with the following script: Set Field [OfficeCases::gSearchField2; OfficeCases::gSearchField2]....the portal filter is: IsEmpty ( OfficeCases::gSearchField2) or PatternCount ( Contacts::Contact Name ; OfficeCases::gSearchField2)I set variables and then use an if statement that detects windows platforms: if [abs ( get (systemplatform)) = 2 ]......then a move/resize window function.... end if; followed by a Go to Related Record function that creates a new window (modal popup)....Hide toolbars, text ruler and formatting bar is off. I would copy and paste the entire script here, but can't figure out how to do that in FMP12 Advanced.I use similar scripts for my other search portals without issue.
To ADD to my last comment:
Upon playing around with it some more; it seems that the problem with the popup window/FMP12 freezing only occurs if the follwoing is done:
1-user types in search critera
2-User clicks on a portal record
IF the user DOES NOT search 9doesn't type into gSearchField2), but rather scrolls to find the portal record, then clicks it, there isn't a problem.
I have 2 other X relationships between these table occurrences,
Please elaborate on what you mean by that. I can definitely imagine ways that could produce a noticeable lag in how smoothly things refresh and can't imagine a reason for setting up the relationship in that manner.
Sure. I have the following relationships: Contacts::NameRefresh X OfficeCases::gSearchfield3 and Contacts::NameRefresh X OfficeCases::gSearchfield4
This makes a total of 3 relationships between the 2 table occurrences.
Actually, that's one relationship with 3 pairs of match fields.
That's not what I was concerned about. WHen you said "between" I was picturing a relationship chain between the layout and portal table occurrences.
"Table Occurrences" are what we call the "boxes" found in Manage | Database | Relationships.
If your portal filter expression is:
IsEmpty ( OfficeCases::gSearchField2) or PatternCount ( Contacts::Contact Name ; OfficeCases::gSearchField2)
why do you include these other match fields in the relaitonship?
What happens if you remove them?
Instead of removing them, I added another table occurrence of Contacts (Contacts 3) and created the relationship: Contacts 3::NameRefresh X OfficeCases::gSearchfield2.
Symptoms persist. Can't seem to figure out the issue here.
You might also take a look at the rest of your layout, conditional formats, unstored calculations, summary fields. You may want to duplicate your layout and then run tests from the duplicate by deleting other layout elements, conditional formats etc to see if that affects the results.
Are you testing this on windows xp, windows 7, windows 8...?
If you try my original demo file out in the same context, do you get delays with it?
Your original demo file works fine.
I removed 4 other portals from the layout. Typing into the search field is still slow/lags but no more problems with the popup window now.....
The next step is to put each of the details that allows the demo file to smoothly update under a microscope to see if there are any differences. For example, check the auto-entered calculation on the "refresh" field to see if it has all the same options specified.
You might also try recovering the file and see if the recovered copy performs differently. Recovering rebuilds all field indexes, among other things and if there's an issue there, the recover might correct the issue. If the recovered file works, you can then try using advanced recovery options with "copy blocks as is" and "rebuild indexes" as the only options selected. This is the one set of options I use on a file when I intend to put the recovered copy into regular use or further development.
You may have a question at this point if the recovered file doesn't lag:
"Why doesn't it lag on the Mac?"
Our database files are a "black box" into which we stuff in some data and then expect to get some data back. We can't see the inner workings to know why a damaged file fails to work correctly--we only can tell that the file is damaged when the ouput is clearly incorrect or when recover or FileDiff tells us that it is damaged. But from prior experience, I can tell you that sometimes a damaged file will function normally on one platform or one version of the OS and not on another.