I have a situation where I want to sort a portal first by date
ascending and then have a second portal of the same information that
is sorted by date descending. Can this be done?

danielemilio (AT) earthlink (DOT) net (Daniel G. Emilio) writes:

Did you even try before posting your question??? Even a novice attempt
would reveal that you can.

Make two relationships, and have one sort ascending and the second sort
descending and place them both on the layout.

loulou

In article <fdd71043.0310081000.e528ebb (AT) posting (DOT) google.com>,
danielemilio (AT) earthlink (DOT) net (Daniel G. Emilio) wrote:

Sort order is set by the Relationship window, so simply create two
relationships then you can use two portals and make sure the fields in
those portals are using the correct relationship.

NOTE: be careful using portal/field script steps on layouts with more
than one portal - you need to make sure you're in the portal you want
first, ie. Go To Field [RelationNeeded::Field].

Helpful Harry
"Just trying to help whenever I can." )

You don't need two portals. You can do this with one portal, a simple calc
and a simple scripted button.

Calc (date result) = If(gNumber = 1, Date(1, 1, 3000) - Date, Date)

(where gNumber = global number field)

The Date function nested within the If function simply subtracts the date
from a date that is larger than any date you will ever use. Can you guess
why? Can you see where I am going with this? If all dates in the portal
are subtracted from the same VERY LARGE DATE, and if the relationship is
sorted by this field, the results will reverse the previous order of the
records, according to whichever of the ascending or descending sort options
have been selected for the relationship.

All that remains to be done is to created a scripted button to toggle the
value in the global field between 1 and nothing:

Set Field [ gNumber, If(IsEmpty(gNumber), 1, "") ]
Set Field [ match field, match field ]

The second Set Field sets the current record match field for the portal
relationship to itself, updating the relationship.

Bridget Eley





in article fdd71043.0310081000.e528ebb (AT) pos...OT) google.com, Daniel G. Emilio
at danielemilio (AT) earthlink (DOT) net wrote on 9/10/03 4:00 AM:

--

(to email direct, replace "DOT" with "." and remove ".invalid")

You rank them manualy?

Ursus

"Old Foggy" <OldFoggy (AT) Foggy (DOT) com> schreef in bericht
news:466baeeb$0$12793$9a6e19ea (AT) unlimited (DOT) newshosting.com...

On Jun 10, 2:38 am, "Ursus" <ursus.k... (AT) wanadoo (DOT) nl> wrote:
Wouldn't it make sense to create a field for the date the architect
contributed and rank on that directly (or indirectly if you require a
1, 2, 3,...scale)?

DKS

Thanks Chris, And how about getting a new entry on the first place (or a
first entry, no previous existing). Did you have a separate button for this?

Ursus

Ursus wrote:

Hi Ursus,

I was usually working with a portal of usually existing records and
shuffling the sort order . Creating the records was the usual button
driven process (prefer not to use direct portal entry). I reshuffled
after creation as I recall.

Creating a new record and nominating where it should slot in the
sequence is perhaps your situation.

The process probably needs to be 2 stage:

create a new (related) record; this does not necessarily have to have a
sort value; this way one can have 2 groups; the important with a a sort
sequence, and the less important with no sort value. The small problem
is that the non valued will sort ascending before those with a sort
value. So the sort value could be auto entered with 100 to effect
sorting last.

(The alternate with two groups, sort value/no sort value, is that you
could filter the portal with a global switch: sorted, unsorted, All.)

This auto enter (or scripted) value 100, can also act as a target
value for the resort script (if only one record has value 100), if all
records are to have a sequential sort value). Meaning once the record is
created, the user doesn't have to nominate which record they want to
place where, only where they want to place the new record.

Stage 2, resort; nominate the row for the new record to come after, then
resort script.

For a normal user situation, rather than ourselves, I would us the same
script for resort to:
click button RESORT:
script tests for $$_Target value; if $$_Target= ""
show message: please select a row for the new record/unsorted record to
follow, then click this button again
end script

user clicks row
row attached select script parses row number to $$_variable (and
establishes a row hilite...)

user clicks button: RESORT
script tests for $$_Target value , which now there is
does the resort, using sort value =100 as the record to move
clear $$_TARGET



there will be some juggling to integrate the 2 requirements of sorting
existing record, and resorting a for a new record. All do-able.



regards


Chris