Portal resets in Preview mode ?

[Thomas An]

Hi all,

A question:

There is a portal with a single row

There is a script that sets this portal row to a specific number.

Once the portal row has been set and then we switch to "Preview Mode" the portal resets back to its first row contents.

Why is it that preview mode does not preserve the portal state ?

Thanks,

Thomas

[Ender]

Huh? How does a portal with one row have more than one row? What does this mean:

There is a script that sets this portal row to a specific number.

Maybe you can post your script.

[Thomas An]

Hi,

The portal is set to display only one row but it has also a scroll-bar so we can browse the rest of the records in it.

Now there is a script that uses a "Go To Portal Row" step to do this at run time via button.

The problem is that the browse mode shows the correct record, but the preview mode does not. (Which is kind of bizarre)

Here is what happens:

http://mywebpages.comcast.net/ThomasAnag/Misc/Screens/PortalBehavior.htm

It is a page that prints labels, but only one label is revealed at a time and printed; the rest are hidden. The page consists of ten instances of the same portal and a script is used to overlay a white container concealing the contents of the rest of the portals. Each portal can be made to jump to a specific record.

[Ender]

Yes, a portal will reset to the top row in Preview Mode. I'd suggest you make your choice of which related record to print be more explicit by setting a parent key so that a new relationship can be established to the correct related record.

This is not too hard. Just add a globally stored field of the same type as the primary key from the child table, then have a button on the portal that grabs the child's primary key and inserts that into the global in the parent table. The relationship would be between the global in the parent table and the child's primary key. When the global is set with the right value, the relationship will show only the selected child.

[Thomas An]

Hi Ender,

Thank you for your reply

It seems that some workaround is in order as you hinted.

At some point I did have it as you suggest, but it required 10 mirror tables and 10 key fields (because there can be one visible label ... or up to 10 visible labels in random visible order)

In the end, I think I am going to drop the portals completely and create 5 global fields (with 10 repetitions each) and then use a script to copy the contents of a record to the corresponding visible repetition)