Guys,

 

I learned this technique from this forum and am thankful for whom provided it. ( Mr.Vodka ) I think.

 

Anyway, I can't seem to wrap my head around why it doesn't work in 12. I can convert a file containing this trick and it works fine. 

 

Has anyone found a workaround or am I just overlooking something?

 

Thanks

MergeVarPortal.zip

MergeVarPortal.zip

The merge variable has to be sized to fit entirely within the portal row.

 

But - why would you use this technique, if you are only displaying field contents?

(And therefore you could use a standard field; or merge field)

The merge variable has to be sized to fit entirely within the portal row.

 

But - why would you use this technique, if you are only displaying field contents?

(And therefore you could use a standard field; or merge field)

 

Thanks for the reply. Could the next person leave the assumptions out and inspect the file I uploaded before posting very basic pointers. 

 

Why would I use this technique to display field contents?

                     Because it's the foundation to building a simple, easy, and elegant hierarchal structure.

My comment comes directly from inspecting your file.

In your file the merge variable is NOT contained entirely within the portal.

The merge variable is over length and hangs WAY off the right side of the portal.

Shrinking it and repositioning it fixes the problem.

This is documented change of behavior for FM12.

Okay your talking about the text object not the merge variable. 

 

Layout has 3 objects.

 

1. Portal.

2. Merge Variable.

3. Text object.

 

The merge variable fits within the portal and is fine. Its the text object which defines the variable that must be resized and placed behind the portal.

 

Sorry thats where the misunderstanding was coming from.

 

Thanks.... 

It is a conditionally formatted object that recalculates for each row of the portal.

 

Therefore it cannot be placed behind the portal. It must be placed in the portal.

It is a conditionally formatted object that recalculates for each row of the portal.

 

Therefore it cannot be placed behind the portal. It must be placed in the portal.

 

The results I'm seeing differ. It must be placed behind the portal for the data in the portal to correctly reflect what it should. The change from 11 is that it must be contained within the first line of the portal and cannot extend outside of it.  The commonality between 11 and 12 is that the object must be behind the portal.

Really? Not the way it's working for me.

12Native.fmp12.zip