AnsweredAssumed Answered

Portal sorting problem moving detail records up or down

Question asked by golife on Nov 2, 2015
Latest reply on Nov 4, 2015 by golife

I am looking for help. PLEASE ))).


I am developing a simple portal representing project team members as shown for each project.

The customer wants to define the order in which team members appear within the portal. So, he can move portal rows up or down, and they will appear in the order defined by the user.


Also I am using the technique "hide object" when there is no associated project-id in the last row where users would usually enter a new portal row and thereby enter a new team member record. So, all entries are done using a popover.


Now, I have a field "Serial row number" visible (1...n), and the user shall be able to move a team member up or down in this order, and all row numbers then will update and show the new position of teach team member.


The sort order is defined in the portal and is not touched (wish of customer).

The portal sorting is set to this portal row number field.


Up- and down-buttons allow moving portal row records up, or down.


My technique here is to get the currently active row number, and I am saving it to a row number variable $rowNum

Then I re-number all portal rows from 1...n so that the current order is established in a correct way.

I commit this step and refresh the portal.

So far it works fine.


The next step is to go to the previously active row number, to the detail record the user wants to move up (or down).

So I am using "Go to portal row [$rowNum] which selects this detail record.

Also this is working.


To move the current record up in the portal order and to keep the sorting order maintained, I must place it before the previous portal row.

Also this is working as I am setting the row number field to ($rowNum-1.5).

The record record is now correctly placed one row up, while the previous record now takes the position of the original current portal row.


I am saving this step using another commit.


But here already problems appear though, with or without a previous commit. Because in the example of 7 rows, and depending from which row I am starting with, the new portal row numbers presented in the portal row number field are not consistent. Sometimes they are correctly showing, sometimes they change invoking the same script again and again. (I am excluding the case of first row at this point, and also excluding the case of moving down in the portal.


Why is this inconsistent behavior appearing?

And then, again I want to renumber all portal rows with this sorting serial number to not present fractions of numbers. Logically this should be easy since going from first row in the portal to the last row through a loop simply should set the correct row number field value from 1...n. And also the record which we moved up would receive a new serial number representing the portal row number.


I tried everything from committing, refreshing, stepping away from the portal and stepping in again, the new numbering also does not seem to work consistently in the same expected way.


What am I doing wrong?


Here is a script (which I use in variants to test all kinds of scenarios).




// Portal sorting is set to field "rowNum" of the project team table instance


Go to Object [ Object Name: "portal_project_team" ]

Set Variable [ $r; Value:Get (ActivePortalRowNumber) ] // The currently user-selected portal row


#Serialize ===========================================================

// Since from previous activities, deletions, etc we can not be sure that the sorting numbers are in correct order

// I am re-numbering all records according to the current sorting order.


Go to Portal Row [ Select; First ]

Set Variable [ $i; Value:1 ]

Set Variable [ $n; Value:Count (PROJECT_Team::fid_ProjectNumber) ]



     Set Field [ PROJECT_Team::rowNum ; $i ]

     Set Variable [ $i; Value:$i+1 ]

     Go to Portal Row [ Select; Next; Exit after last ]

     Exit Loop If [ $i > $n ] // Should not be needed here

End Loop


#Serialize END =======================================================


// Now I found that I have to commit, otherwise continue with additional editing the new sorting numbers get lost.


Commit Records/Requests // Test: with or without this script step

Refresh Object [ Object Name: "portal_project_team" ] // Test: with or without this script step


Go to Object [ Object Name: "portal_project_team" ] // Test: Reentering the portal as focus went to another portal test


Go to Portal Row [ $r ] [ Select; No dialog ] // The originally saved portal row with the record to be moved up

Set Field [ PROJECT_Team::rowNum ; $r-1.5 ] // Moving record in the sorting order before the previous record/row


Commit Records/Requests // Test: with or without

Refresh Object [ Object Name: "portal_project_team" ] // Test: with or without


// And now after committing I want all records in the portal to be re-numbered using a the sorting number.

// But problems appear already even before this last step.

// Especially when the user is repeatedly pushing the record-move-up button in the portal, even when pushing in the same portal row.

// Since the sorting numbers would be re-assigned going from portal row 1 to n, those numbers are not appearing as expected.

Something may be going on in memory? Refreshing or not, committing or not... I tried everything, and all has a definite influence, but there is no consistency in how the sorting numbers are entered through the system.

In the end, this portal must be error-free and stable and always work as expected. I am thinking that instead of a automatic sorting in the portal, it might be better to sort associated records in the related table instead and assigning new portal row numbers there.

The problem may be that here there is an underlying dynamic sorting - which is usually also desired - but during this operation of moving a record up (or down) it should be disabled. I could not find a way of doing that.

(I can not resist in giving a last comment about scripting with FileMaker: The art of developing with FileMaker seems to be the skill of finding and applying work-arounds, since there is not too much a scripter can define and programatically do, always trying to trick FileMaker into doing things that is normally would not do.