Renumbering and moving around of portal records

[djgogi]

Recentely, there were some questions about how to dinamically renumber related records in portal and how to move them up and down.

This files try to answer those questions.

Hope you'll find them useful.

Dj

Renumbering Portal Records.zip

[djgogi]

Well, arghh I didn't "have" time to do some proper test on custom sorting.

Any way, now I've fixed it.

How to use it.

There are 3 layouts:

Sorted

Unsorted

Custom

On "sorted" you can see how to update, dynamically, when inserting (the portal is enabled for creation of related records but in an real implementation this should be avoided whenever possible) new records or deleting existing ones, when the related records are sorted on some criteria.

The only limitation is that the field (or combination of fields) used for sort has to give UNIQUE value. The simplest work around is to define an sort field (as in example) in related table which includes unique identifier.

It also shows the implementation of chaining between records (iow previous and next) that will update accordingly

On "unsorted" you can see the related record in their creation order with default chaining.

Finally, on custom you can move rows up and down, to the top or to the bottom, always with dynamically updating of rec number and previous/next IDs.

Renumbering Portal Records.zip

[Ugo DI LUCA]

Hi DJ,

As always, your posts are so helpful.

I wanted to add a precision to your post. I hope I am not the only one that hadn't clearly understood what your solution was leading to.

So there it is When you drop a related field in a layout, FM automatically displays the first related record. When renumbering a portal in that way, you also update the relationship, that is that you can move up/down any relation record.

Some days ago, one nice guy on that forum was looking for a way to set a "Default" adress. I replied he could create an Adress file, and flag the Adress he wanted to be display as the default adress. Looking back to my own Contact file and to your sample file, I implemented it following step by step your clear attachment.

Using your "custom" method now allows me to update a set of related fields for adress I dropped on my layout. I surely would use it in some other situation now.

Looking in detail to your attachment, I now have 3 questions :

1. There are 2 moveTop scripts :

The first use a simple Set field step Set field (CustomOrder, Seljoin::CustomOrder-1)

The second, not used in your attachement, use Set field (CustomOrder, Left((Seljoin::CustomOrder-1)&Right(10^10,10),10))

What could be the difference from these two methods ?

2. What are the purposes of your "go to related records" script steps when used for creating records or move to previous/last record within the Parent file ?

3. You say the implementation wouldn't work if the "somedata" is left empty, but I currently have a "complementary adress" field that is sometime left empty. And it works great. What is it that shouldn't work ?

Thanks again for sharing...

[Ugo DI LUCA]

djgogi said:

Finally, on custom you can move rows up and down, to the top or to the bottom, always with dynamically updating of rec number and previous/next IDs.

Well, not really. I've just noticed that the rec number won't update correctly on the "Move Up" or "Move down" scripts. Actually, that record that was up has its Custom Number turned to 0. Not a big problem as the main purpose (moving rows) is working.

As I didn't wanted to mess-up with the calcs, I introduced a global field and used this script :

There may be another technique though...

Freeze Window

If[not Is Empty(Previous::customOrder)]

Set Field [g_custom, Previous::customOrder]

Sort[customOrder(Ascending) - Restore,no dialog)]

GoTo Record[first]

Loop

End Loop If [cutomOrder=g_custom]

GoTo Record[next]

EndLoop

SetField[customerOrder,Next::customOrder]

GoTo Record[next]

SetField[customerOrder,g_custom]

End If

Exit Record

Same for the Move Down script.

The strange thing is that I needed to sort it again to make it work, even if the portal shows record sorted already.