AnsweredAssumed Answered

Making a script reusable.

Question asked by Cécile on Dec 16, 2018
Latest reply on Dec 17, 2018 by philmodjunk

I have a button that does the same thing on a couple of layouts. The only thing that changes is the TOs names.

I thought I could pass them as a parameter and simply build the reference like $TO & "::g_listeChoisie" for example.


The script itself is pretty simple so I did not think it would be so complex to dry code it!



I encountered a few obstacles.

First: getting the parameter:

Get(LayoutTableName) gives me one of the TO but how do I get the RTO? Three ideas came to mind:

1) no related record field being selected at that time, can't use Get(ActiveFieldTableName).

2) I thought I could extract the suffix of the Layout Table name (eg: signifiantOUT=signifieOUT, signifiantLV-signifieLV, all TOs of a given table share the same root and each pair sharing the same suffix.) But the current naming convention only applies to my utility tables, elsewhere I use a variant of the method suggested in the Training Series. So in the long run, solving it for this case would not teach me anything for the future.

3) I thought of using GetValue (RelationInfo ( Get(LayoutTableName)); 2) but again, in situations where there would be more than one related table this would not work.


Second: the sort context

4) Afaik, the sort context cannot be calculated...?

5) Sorts triggered when loading a record are applied on the found set right? not on the RRs right?

6) i could catch the error to avoid the warning: the sort seems to happen even if not the right context, but maybe that was coincidental?


I should not have been spending so much time trying to DRY it and I have already duplicated it and change manually the references so each button has its own script but I really would like to find out if there are ways to achieve this one script for all, as this type of situation will present itself over and over again.