Prevent portal scrolling back

[kfok]

Is there a way to prevent the portal list from scrolling back to the first line when you leave the portal?

[ernst]

No.

You can in some cases use a fixed portal (without scrollbar) and have a calculated field on the left side of the portal relation that controls the visible records in the portal.

An example:

http://www.fmforums.com/threads/showflat.php?Cat=&Number=70247&page=3&view=collapsed&sb=5&o=&fpart=1

[stanley]

Actually there is. I'm going to have to dig through the scripts at one of my clients' tomorrow to see how I solved the problem, and if I remember, I'll post you the answer tomorrow evening. If I forget, you can remind me.

-Stanley

[stanley]

Okay, the solution I found involves the following scenario:

1. There is a portal with a list of jobs in it (20 rows, often holds 150 jobs) from JobsDB

2. There is another portal with the details of those jobs, also from JobsDB

3. When you click on an item in portal 1, details show in portal 2.

Originally, when an item was clicked in portal 1, it would return to the top. The client was really unhappy with this, as many jobs had similar names, and he couldn't go through the list without getting lost. To keep him from getting lost, the following script was added to the portal (it is a button which covers the whole first row (i.e., all rows) of the portal.) ("GlobalJobNumber" is a global number, used only by this script.)

Set Field ["GlobalJobNumber", "Status(CurrentPortalRow)"]

Go to Related Record ["JobsDB"]

.. then a bunch of other stuff ..

Go to Portal Row [select, "GlobalJobNumber"]

That's it. It leaves the row you selected highlighted, but it has one quirk. If you have a very long list of items (such as 150, in a portal that only shows 20) and you are somewhere in the middle of it, it puts the highlighted portal at the very bottom of the visible rows. This is a minor inconvenience, as it gets the job done, and that's what it is all about.

Hope that helps. It certainly helped me.

-Stanley

[Ugo DI LUCA]

Hi Stanley,

I was waiting for your suggestion.

Yes, remembering the portal row is a good option that I also used before going to fixed portal. I finally found it more interresting, even if the scrowling part is somehow difficult to implement to give satisfactory results.

[ernst]

Hey Stanley,

I tried this (being curious) but found that as soon as you click somewhere outside the portal, or enter a field outside the portal, it scrolls back anyway.

Am I doing something wrong?

Regards,

Ernst.

[-Queue-]

No, that's the proper behavior, Ernst. This technique only 'locks' the portal when you click a row's button, which is what was desired for the specific example of setting one portal's information from another without losing the current row. It's like a regular portal in all other respects, so if you click out of it, it's going to reset itself.

[Ugo DI LUCA]

That's why the Fixed Portal stays the only solution we know...

In Stanley's example, the user leaves the portal to have an "overview" of one particular record. In that instance, I would even not complain about the portal scrolling back. You'd only need to bring the 'related' portal fields together with other related information in a set of related fields in a big box.

So you'd still keep in mind which record you're browsing as far as you don't move from records to records into the Main File (or that you implement a "clear global" script step while moving).

What gives more credit to the Fixed Portal is a situation where the user would need to enter some other fields in the Main file while keeping present the selected row of related records.

Or in occasion where the user loves having his mouse pointed right nowhere on the layout (I'm this user).

Still I was curious too...

[ernst]

Guess I was hoping for a small miracle...

Ernst.

[stanley]

Sorry to disappoint you guys with an old-hat solution, but I thought that is what kfok was after. Now that I've reread the original post, I can see that I was probably wrong. For what it's worth, I'd only use the method I described when the layout is not used in an editing situation - as in the example, to display tons of information, where pretty much the only thing happening is scrolling through portal 1 to display detailed information in portal 2.

That, and it was precisely what the customer wanted, so... we all know what that means.

-Stanley

[Rebel Minion]

Ok, let me first just say that there is a way to have a portal list where you can click one of the items to get details elsewhere on the same layout and to NOT have the portal list scroll or move in ANY way.

I actually have a solution I created a few years ago that does this. However, and this is the emberassing part, I am not 100% sure how I did it : .

I have a solution I am working on now where I want to do the same thing, and I will be damned if I can figure out how I did it. I do know I got it from a reference book. It might have been sciptology.

I just moved and cannot find my box-ful of FM books.

Just wanted to let you know it can be done. I am on a mission to dissect how I did it. As soon as I figure it out, I will post the technique here.

[comment]

In Layout Setup, disable 'Show field frames when record is active'.

[Rebel Minion]

Ok, I have this figured out.

Let me start from the beginning.

Lets say our main table is called "MainTable"

First, setup a global field to hold a users selection for what he or she wants to view in the portal you want.

So, in my case, I have a field with checkboxes (could be any field type, does not matter) titled gType.

Now, create a self relationship from gType to Type (Call this TypeSelectRelation instead of MainTable 2). Remember, gType is only holding what the users current selection of type is. Type is what each individual record has for this value.

The portal should be based on the relationship TypeSelectionRelation. Place fields in the portal based on the TypeSelectRelation.

You now have a portal that will only show what the user has selected for type.

Now, lets say you want the user to be able to click a record in a portal row and have the details of that record brought up in the same layout at the bottom for some purpose (maybe there is more detailed information available, maybe you want to setup the editing of data this way... whatever).

Create the global field gID. In this case, this field is going to hold the unique ID value for the record you click on in the portal.

Create a self relationship from gID to ID. This assumes you have a field unique ID field for each record. Call this IDSelfRelation

Create a script setup in the following way:

Set Field

TARGET: MainTable:gID

CALULATED RESULT: TypeSelectRelation:ID

Assign this script to all the fields in the portal, or just one... whichever one you want users to click to get details.

Then, elsewhere on the layout, place the detail fields you want the user to be able to see, edit, whatever. Get these fields from the IDSelfRelation.

Your all set. Now when you click the portal row, you will get the details below with no reset of the portal to the first row.

What was throwing me off before was I was getting the detail information via a different relationship. I was getting the info, but it was causing the portal to reset. Once I changed to the relationship noted above it worked like a champ.

The only downside to this method is that there is no visual que in the portal as to what row is currently selected. I simply duplicate the main title or item in the detail view so that users know which row was clicked.

[Ender]

The only downside to this method is that there is no visual que in the portal as to what row is currently selected.

You can use an unstored calc to show a graphic or whatever:

cCurrentRecordHighlight (calculation, container result) = case(gID = ID; Highlight_Graphic)

Place this related calc in the portal to highlight the current row.

[Rebel Minion]

Good idea.

Thanks!

R