I have a portal showing records from a self-join relationship such that
while I am looking at the record for an item, I can also see a list in
the portal of other items from the same table with a matching category
field. Of course the portal list includes the item I am currently
looking at which is useful to show it in a sorted context. What would
be even more useful is if the current item was highlighted in the
portal.
I know this can be done by enforcing navigation through scripts
attached to buttons in the portal; I have done this before and found it
so complex as to be impossible to make user-friendly and fool-proof at
the same time. There have been a few discussions of this type of thing
on this newsgroup over the years, but nothing recently and I feel sure
that FM8.5 might at last have a Get() function I have overlooked or a
new bit of relationship functionality which makes this relatively
simple. Please tell me it is so! ;-)
Thanks, helpful people
Alan

Interesting challenge. There are a couple Get() functions, like
Get(RecordNumber) and Get(RecordID) but the problem is that a calculation
can only have ONE context, even if you are referencing from two different
table occurrences.

For example,

R (calculation, number result, context="MyTable") =
Get(RecordID)

When placed in a portal will show

- the active record's RecordID if you use MyTable::R,
- the current portal row's RecordID if you use MyTablePortal::R

BUT there is no way to access both results from a single calculation field.
Even if you set up separate fields like Rmain and Rportal (using the Get()
function) evaluated in different contexts and try stuff like

MyTable::Rmain = MyTablePortal::Rportal

with different contexts and different source TOs in the portal, it doesn't
fly.


<braedsjaa (AT) yahoo (DOT) co.uk> wrote

braedsjaa (AT) yahoo (DOT) co.uk wrote:


Disagree, this is really quite simple and bullet proof.

create a global to hold the selected portal record record ID ; g_ID
the portal self rel uses constant::constant (I assume, to show all self
records)
click row select script parses the selected portal row ID to the g_ID
(for the hilite) and then navs to the selected record; in THAT order

a global container _hilite holds the hilite colour
a calc (container) in the record table displays hilite for selected
ID/record

If( ID = g_ID; _hilite; "")

place the hilite on the portal row, behind the data field (and with the
data fields having no fill colour) Format/graphic: enlarge, and un-check
maintain orig proportions


result: click portal row, go record, portal row same record hilighted


regards

Chris
University of Adelaide

Looks like you are saying "run a script when clicking the portal" which
is just what I was trying to avoid.
With this type of system, if you use the standard status area
navigation controls the highlighted portal row doesn't change, so you
have to replace that option with scripted navigation; or if you arrive
at a record through a relationship or a Find operation then those too
need to be scripted in order that you can control "switching on" the
highlight; and any other scripts which might bring you to a record on
this layout will need a sub-script to check the highlight status. YUK!!
I have become tired of tying up all the loose ends in such a system and
often the processing overheads start to outweigh the small ergonomic
advantage for the user.
I guess another way to put my request is that I presume FileMaker must
"know" where the current record is in a portal and should easily be
able to point it out to me.

In article <1168517010.876048.162270 (AT) k58g2000hse (DOT) googlegroups.com>,
braedsjaa (AT) yahoo (DOT) co.uk wrote:

FileMaker doesn't know where (or even if) the current record is in any
particular Portal. It also doesn't know which is the "active" record
within another file / table.

The problem is that the Get(CurrentRecordID) function only works on the
"active" record from within a script. If you try and use it in a
Calculation field you'll simply get the record's own RecordID since at
the time of calculating that is the "current" record.

The only way to do what you want is via scripting.

Helpful Harry
Hopefully helping harassed humans happily handle handiwork hardships ;o)

braedsjaa (AT) yahoo (DOT) co.uk wrote:

Ah, I lock out Status access because I want to control record and layout
navigation; scripting allows me to commit and setup such niceties as
quasi default hilighting, parameter sniffing etc. I see it as a basic
design element.


regards

Chris