Sort Records by Field - don't "keep records in sorted order"

[TJ53]

Is there any way to not keep records in sorted order when using the script step "Sort Records by Field"?

[comment]

What exactly do you mean by "not keep records in sorted order"?

[TJ53]

In the "Sort Records" script step, there is a checkbox to "keep records in sorted order", that is checked by default, but it can be unchecked (left bottom in the dialog window).

But the "Sort Records by Field" script step doesn't have that checkbox so it always keeps the sort order. This is confusing when the user is in form view, because when the user edits the field used for the current found set sorting, then the position of the record relative to the found set changes. 

[comment]

I am not sure what difference the position of the record relative to the found set makes when you're in form view.

In any case, I don't think there's a way to prevent re-sorting on commit other than having a script running or paused:
http://www.filemaker.com/help/16/fmp/en/#page/FMP_Help%2Fsorting-records.html%23

Or use If / Else If / Else to select from multiple Sort Records [] steps.

[TJ53]

Thank you for your reply. Regarding this:

Quote

I am not sure what difference the position of the record relative to the found set makes when you're in form view.

Let´s say that I have an invoices list sorted by status: "not paid" / "paid". So when "keeping the sort order", the not paid invoices are grouped first, and then there is the group of paid invoices. Now, if you change the status of an invoice from "not paid" to "paid", then that invoice will change its position to be in the "paid" group. If the user is in list view, he can see what's happening (the record changing its position in the found set), but if the user is in form view, it's confusing ... especially if the user navigates to next or previous record after changing the status of an invoice.

In the "Sort Records" script step this is just a matter of unchecking the "keep records in sorted order" checkbox.

But in the "Sort Records by Field" there is no such checkbox, so it's always keeping the sort order after committing the record.

The reason why I would like to use "Sort Records by Field" is to be able to dynamically sort records by just passing a script parameter with the name of the field (object name), so I don't need to hard code several "if - else " statements. So the script is something like this:

(first: name the sortable fields in the layout)

- set variable: $field_object_name = get(scriptparameter)

- go to Object ($field_object_name)

- Sort Records by Field

The problem is, I don't want the found set to keep records in sorted order, but it seems there is no way to disable this with the Sort Records by Field script step ... unless somebody has come up with an alternative way of doing this!

 

[LaRetta]

I see the issue, thanks for explaining it further.  The only suggestion I have is to:

Set Variable [ $priorRecordNumber ; Get ( RecordNumber ) - 1 ]
... put your existing steps here
Go To Record/Request/Page [ by calculation ; $priorRecordNumber ]

This would put you at the last 'not paid' record before you changed the next one.  Would that help?  I would also suggest making the suggestion to FMI. :-)

On second thought, you could drop the -1 and should land on the 'next' record in sorted order.

[TJ53]

Thank you for your suggestion LaRetta, unfortunately that wouldn't work for this case since the user would be confused to see that the record "disappears" after committed (it would land in a different record).

I think one of the biggest limitations of FM scripting is not being able to perform a sort based on criteria passed by a parameter. I thought I had that solved by using Sort Records by Field after going to the object (named field) based on the name passed as script parameter... and just noticed the limitation of not being able to "not keep the sort order". 

[LaRetta]

50 minutes ago, TJ53 said:

I think one of the biggest limitations of FM scripting is not being able to perform a sort based on criteria passed by a parameter.

I agree.  It appears that you are hard-coding the field name in the object name?  That makes your solution vulnerable if field names ever change (or table occurrence names change (?).  Since you are going to the field anyway, are you instead setting the script parameter with:  Get ( ActiveFieldName) and skip the hard-code.

Another option ... why not find unpaid records first?  In that way, the record set would not be sorted and the record would not disappear when changed to Paid.  Anyway, I wish you well with your project!

[TJ53]

Thank you Laretta. Please see attached example of what I'm doing. The idea is to try to workaround the scripted sorting limitation of FM by naming fields in the layout and passing the name as parameter.

Actually, if FM had a script step "Go to Field By Name", the parameter passed could just be GetFieldName ( field_for_sorting ), and having to name the objects in the layout could be avoided. This is another limitation of FM scripting ... we have "Set field By Name", "Go to Object (object name as calculation)", but we don´t have  "Go to Field By Name" ...

Anyway, please let me know what you think about how I'm doing this ... I just want to avoid a bunch of "if - else" statements ... any suggestion is welcome, thanks!

Sort_by_field_object_name.fmp12

[bruceR]

Sometimes it's better to just recognize and accept current limitations, proceed to do a few minutes work, and get a clear, scripted solution.

Which provides the result you need and provides a script that you can adapt, monitor in debugger, print, review, etc.

See attached mod to your file.

Sort_by_field_object_name_MODBFR.fmp12

[TJ53]

Thank you very much Bruce for your modifications, it looks good and crystal clear. I think it's a good philosophy you mention, I´ll definitely take it into account. I guess I often try to minimise the number of lines of codes and make my scripts modular, but I understand your point that this sometimes this goes against readability and easier debugging, I'll definitely look into that!

By the way, I've been using your virtual list technique and I would like to take this opportunity to thank you for such great contribution to the community. I guess this belongs to a different topic but ... would your technique benefit if adapted to be implemented using the new FM16 JSON functions?

[bruceR]

You're welcome. Short answer re JSON; would adapt well. Have not pursued it yet. Yes, probably better to start a different thread, some examples might get submitted.

[TJ53]

Sounds good! looking forward to that.

[bruceR]

Thought you were saying you would start the thread! So - we'll see.

[LaRetta]

TJ53, could you please update your profile?  It helps us when we respond to your questions.  Thank you!  :-)

[TJ53]

10 hours ago, BruceR said:

Thought you were saying you would start the thread! So - we'll see.

I just did! looking forward to some replies

 

10 hours ago, LaRetta said:

TJ53, could you please update your profile?  It helps us when we respond to your questions.  Thank you!  :-)

Done!

 

 

 

[Wim Decorte]

21 hours ago, TJ53 said:

I guess I often try to minimise the number of lines of codes and make my scripts modular, but I understand your point that this sometimes this goes against readability and easier debugging, I'll definitely look into that!

"Premature Optimization is the root of all evil"...

Code efficiency and modularity is important, but not as important as solving the problem at hand.  It's a fine balance to strike.

[TJ53]

Thank you for the tip! I'll definitely keep it in mind.