Thanks for the post...intriguing question...I look forward to some of the finesse solutions I'm sure will be posted.
For little brute force me, though:
1. The Portal Setup overrides whatever sort you want to do.
2. Not sorting the records in Portal setup is probably a bad way to go.
So why not have your script go to another layout that is the same in all respects except that the portal setup on Layout #2 has a different sort order?
You don't have to resort the portal...you only have to LOOK like you resorted the portal...I'm sure there's a song in there somewhere...then add your pause and continue back to your original layout.
Work like a hammer?
Hi, a little old post but however ...
i have the same problem as above. the solution suggested from ninja at least is a solution i could use - but couldn't that be solved in a better way?
having a number of layouts just to present the same data in a different sorting... i would mean for example if i change the font or something i have to change is in every single layout, or am i wrong?
If you could sort the portal dynamically, would that get you going (ie: leave you to fit it into a script, etc)?
Let's say you want to sort the portal by Name or by Location, ie: click between the two. Or from Quantity (ascending) to Quantity (Descending).
Create another calculation field in the table, called cPortalSortValue, and a global field gPortalSortType, with a pop-up of 'Name' and 'Location' (say). Set the portal to be sorted by cPortalSortValue.
Set the cPortalSortValue =
Case ( gPortalSortType = "Name" ; NameField ; LocationField )
As you change the global field the portal will re-sort. You may have to add a script line to refresh the screen, or trigger another field to force a re-draw.
For ascending to descending quantities, just set it as:
Case ( gPortalSortType = "Ascending" ; QtyField ; -QtyField)
Note that I have chosen a couple of easy examples but there are ways around trickier sort options.
You could just use the traditional presentation of clicking the portal column header to trigger the sort, of course
I too have a PORTAL SORT question.
I need my portal to sort on a PaidYear column (numeric) dynamically. By that I mean if the column has the values:
==== When the user exits (via an Exit Script), the column would resort. So far I can't get it to happen. Any ideas?
Are you changing, or entering, the year in the portal itself? I assume the portal is already set to sort by year, but what you mean is when you enter a new year out of sequence or amend an existing year it doesn't re-sort?
If that is the case the record needs to be made to refresh the screen. There are several ways to do it, but you could try setting a two-line script to run on ObjectModify on the year which goes into preview mode and back into browse mode.
Before doing that, even, I assume if you browse away from that record and come back to it displays as sorted correctly?
Thanks Sorbsbuster for the ideas.
I think I neglected to sufficiently describe the 'whole' situation.
My portal has the fields: DATE -----PAIDYEAR-----DONATION----DUES-------ASSESSMENT
When a user enteres the date, my system automaticvally puts the associated Dues and Assessment according to their membership type: (ie Life, Yearly etc) No problem here, this works.
And, I can do an ONEXIT or ONSAVE script on the PAIDYEAR field to get the table to 'resort'. This works.
BUT, the problem is that sometimes, after the PAIDYEAR is entered, the user wants to move to the DONATION field. This triggers the script which resorts the table. In this circumstance the user must 'visually search' for the year to go across to find the correct DONATION field.... ugh... So, to solve this problem I put a '+" button on the column head that will (if the user remembers) resort the table by YEARPAID. But, users 'forget'
The "REAL" solution would be if there was a script step that would look at the portal row and then on PortalRowExit would fire the script. This would give the user ample time to enter whatever they wanted, whereever they wanted in the current row. But, it seems like the ScriptTriggers for portal rows only affect ALL the objects on the portal; not the portal exit situation.
Please forgive me: I'm only a simple Irish Country Boy. All this talk of script triggers makes me come out in a rash. What you seem to have is a portal that is sorted by PaidYear. Some of those PaidYears may be blank (or need to be updated). When the user goes to update the portal row with more data, they enter a PaidYear, which then makes the portal re-sort the records (by the existing sort criterion: PaidYear) and therefore the record they were editing is no longer where it was a second ago? So they have to look through the portal to see where the record they were editing has jumped to?
I've never, or rarely, let users edit portal rows. I just see them as display features; I make them click the portal row to take them to a form layout where they can edit away to their heart's content - but I'm not saying what you're doing is wrong - I'm only exposing that I don't have any experience of what happens as the user edits across a portal row. If you didn't have any script triggers on any of the portal's fields, what happens if they just edit the PaidYear and then tab across to the Donation field? Do they not stay on the same portal row, fill in all the details they want, then exit the portal, and it resorts itself, by the same (original) criterion - YearPaid? At that stage the row they were editing will indeed jump, but they have now finished editing it.
You orginally said that you wanted a portal of 2009, 2010, 2013, 2011 to sort again. Is it not the case that all you have to do is wait for the user to finish editing, and then once they commit the record it will re-sort the way you want? Or is it just that when they (only) commit the record, the portal still looks the same, and requires a screen re-draw to force the re-sort to display?
If I'm only adding to the confusion I'll duck out, no offence taken, honest.
When the user goes to update the portal row with more data, they enter a PaidYear, which then makes the portal re-sort the records (by the existing sort criterion: PaidYear) and therefore the record they were editing is no longer where it was a second ago? YES! So they have to look through the portal to see where the record they were editing has jumped to? YES!
I've never, or rarely, let users edit portal rows. I just see them as display features; I make them click the portal row to take them to a form layout where they can edit away to their heart's content Interesting idea. But, it doesn't seem as simple for the user.- but I'm not saying what you're doing is wrong - I'm only exposing that I don't have any experience of what happens as the user edits across a portal row. If you didn't have any script triggers on any of the portal's fields, what happens if they just edit the PaidYear and then tab across to the Donation field? YES! Do they not stay on the same portal row, fill in all the details they want, then exit the portal, and it resorts itself, by the same (original) criterion - YearPaid? YES! but I want the user to be able to see the 'results' of the sort before or immediatley after leaving the portal. At that stage the row they were editing will indeed jump, but they have now finished editing it.
You orginally said that you wanted a portal of 2009, 2010, 2013, 2011 to sort again. Is it not the case that all you have to do is wait for the user to finish editing, and then once they commit the record it will re-sort the way you want? Or is it just that when they (only) commit the record, the portal still looks the same, and requires a screen re-draw to force the re-sort to display? I can either attach a ScripTrigger to the sort event. But to attach it to the Date field means EVERYTHING gets sorted before the user can input into the Donations field. If I attach the ScriptTrigger to the Donations field and the user does NOT make a donation, then there is no sort.
What would be best is for the PortalRow to have a ONSAVE ScripTrigger that would fire when the user moved to a new record or committed.
I think I am going to work on tracking the related key on Dues when the record is created, then sort it and then goto that related key followed by a jump to the Donations field. Thanks for your ideas.
If I'm only adding to the confusion I'll duck out, no offence taken, honest.
I'm using FM11, I have created two tables. The portal to the child table has a name and a date. The portal (not the relationship) is sorted by date. When I change the date and click off the portal and on the record (ie: commit it) the portal sorts immediately, the way you would want.
Yes, I can see that will work. But, the problem is that I have a field outside the portal called STATUS (Which holds values like 'current', 'late','NPD'...etc.
Status is determined with the following ScriptTrigger (named STATUSUPDATE)
IF Dues::PAIDYEAR < year(get(currentdate))
Since the user may enter into the portal a DUES::PAIDYEAR that is totally out of sequence AND since FM, when asked for the value of DUES::PAIDYEAR, always picks off the TOP ROW FIELD, it is necessary sort first and then run a script which will update the STATUS.
Without the sort, the most current DUES::PAIDYEAR could be at the bottom of the portal and the STATUS would be inaccurate.
So, I MUST SORT and THEN RUN THE STATUSUPDATE (seen above).
The problem is that there are portal fields to can be optionally filled in. If I enter a date and then sort, the current 'row' jumps into it's sequence and it is a 'hassle' for the user to find the next field to fill in. Or, if I attach a 'sort button' to the portal, the user must 'remember' to push it when he is finished. Either way, it seems an error prone process.
The REAL solution is for FM to make portal Script Triggers that would fire when the portal row is saved. May with FM 12???
That great Poster 'comment' would always strongly recommend that you do not rely on scripts or script triggers for calclautions, and I think that is sound advice. Why do you not base the Status calculation on a relationship that is sorted, but base the portal on a portal sort?
That way the portal draws upon exit just the way the test did, and the calculation will always pick the first (latest, whatever), and you don't need any scripts at all.
About the proposed relationship:
Since Members <-->> DUES, and since STATUS is in Members and PaidYear is in Dues, what would that relationship look like? What would connect to what?
Also, the Members::STATUS does NOT always pickup the most current DUES::pAIDYEAR. But, it DOES always want the Max(PAIDYEAR). [Yes, I tried to create a summary field based on max(PAIDYEAR) but that didn't work.)
I would be pleased to not have any scripts but I don't see how to NOT have any. Can you be more specific?
You know your table and field and relationship set-up better than anyone. All I'm suggesting is that if you are able to set a field value (Status in this case) by a script that uses a calculation to set the value, why not use that same calculation as... a calculation?
Your only stumbling block seemed to be that you wanted the relationship in that calculation to get a certain (max or min) sorted value, which was not the same sort, necessarily, as the portal diaplayed at that time. I'm just suggesting that the display sort of a portal can be handled one way (just set the portal sort to be by PaidYear) and everything displays the way you want it. Then use a totally independent relationship, if necessary, to get data for the calculation. That may even be the same relationship: for example, you could sort the portal by PaidYear, but sort the relationship by another factor(s) altogether. You could define another relationship with the sort you want, just for that calculation's purposes. As you say, you could simply use Max (CorrectRelationship::PaidYear ) to see what the maximum year was. (I don't see why you would have used a summary there, if all you are after is the latest year itself.)
You seem to have all the components you need to perform the calculations you need, and they all work. I would just be concerned that your data is dependent upon a correctly-run script. I just don't see why you can't stitch the same components together in a direct calculation.
There is always the distinct possibility that I'm missing something important.