Is it possible that in the portal on the layout, the very top edge or bottom of the fields is touching or in the next row of the portal? Try making the portal rows taller and make sure all fields are within the portal row. Also, make sure there isn't a portal behind the front portal and make sure the fields are not behind the portal. Obviously this is not supposed to happen, so it even could be a bug or a corrupt file. If you make a new layout, can you recreate this portal and does it work?
Make sure the object with the conditional formatting calculation setting the variable is behind (with the same position, just further back in the z-order) the object containing the merge variable. FileMaker appears to render layout objects (an execute their conditional formatting calculations) from back to front, so we need to be sure the setting of the variable and the display of the set value are happening in the correct order.
I just put a proof of concept together and am getting the same results. In my initial example I was declaring the variable inside the text block that is displaying it. I tried breaking it out and having the declared block ahead of the display block and have the same thing. I'm attaching the sample file, so hopefully we can get to the bottom of this.
Thanks for the responses!
I appreciate the demo file. I tried looking at this the other day, but could not reproduce your experience.
Attached is a modification to your demo file which seems to behave as we would desire. Presently I don't have a good explanation for why this is working and yet did not work for you when you tried the same thing. Perhaps you can identify what is different?
Crazy. I opened the file and it worked, but when I went into layout mode and back it flipped to what I saw before. Seems like a FileMaker bug, maybe?
Did you remember to say "Simon Says: Set my merge variable" ?
That is indeed strange.
I am running the following:
FMPA 12.0.v2 (not the most current version)
From Tech-Net I downloaded the archive that I uploaded, opened it, and switched back and forth between layout and browse modes several times, and all remains per my screenshot, i.e. what we would hope for.
Do you feel like posting the now-broken version of the Mod01 file? I'd like open it on my machine and see what its behavior is.
That file is still behaving perfectly normal for me. The symptom that you see on your system is not evident over here on my system.
I believe that in the first couple of revs of FM12, there were considerable changes to how the conditional formatting was implemented -- specifically aimed at improving performance. In particular, when and how frequently a conditional formatting calculation would be re-evaluated underwent some changes. I wonder if that is coming into play here, given the difference of versions that we are running?
Also perhaps of interest:
I seem to recall that LaRetta posted an interesting post here (and on FMForums) regarding something that (as I recall) is either related or very similar. I will try to find that thread and post a link to it. Perhaps she already came to a conclusion that would help out here.
Edit: This was the thread that I was remembering: http://fmforums.com/forum/topic/88038-hover-triggers-merge-variable-update-by-itself/
Message was edited by: steve_ssh. Added reference link.
I tried it on one of my test machines running 10.7 and FMP Advanced 12.0 v1 and it was fine.
I updated that install of FMP to v4 and it broke. So somewhere along the update line it broke.
supposing we entertain the premise that:
In 12.0v4 , regardless of z-index, and regardless of order in which elements were added to the layout, within a given portal row the conditional formatting calcs are always going to be evaluated after the data to replace into non-global merge variables has been established.
If we entertain this idea, it raises two questions:
1) What happens if you use a global ($$) merge variable instead of non-global ($) ?
2) What happens if (instead of conditional formatting) you use a tooltip calculation as the host for your Let calculation which sets the merge variable? (Paying close attention to z-index and order in which elements are added to the layout)
1) Global variables doesn't change it at all.
2) Tool tips will set correctly, but the display variable doesn't refresh to reflect each line. All the display variables are the same. I'm applying the tool tip to the field, and it is stacked on top of the text object with the display variable (I'm assuming that's what z-index is referring to).
Rather blunt thinking on my part: The tooltip isn't going to trigger until someone hovers over it.
So in that case it works properly. If I trigger the tooltip then refresh the window, then all the display merge variables update to the most recent tooltip.
Yes. That totally makes sense. Sorry about the bum lead there.
It also occurred to me that we might see about what we might be able to get out of using the portal filtering calculation to be the host for the Let statement. I just tried that a minute ago, and it does not appear to serve our purposes...