Hi Dojo,
Is there any benefit in using SLProtocol.GetLocalElement over just IDms.GetElement? More generally does use of ILocal variants provide benefits?
Is there any documentation that explains these benefits and use cases? All I've been able to find just "exported summaries".
Thanks
Hi Edib,
When you want to perform operations on the local element, it's advised to use GetLocalElement.
This is because the methods that are defined in e.g. the ILocalElement and ILocalTable interfaces will perform calls through the SLProtocol interface.
See this as a direct interaction with the process that contains the element.
Also, this allows to retrieve data from parameters which do not have RTDisplay set to true.
Using GetElement is used when you need to interact with elements other than the local element.
The calls in the interfaces obtained via this method (e.g. IDmsElement, IDmsTable, etc.) are basically wrapped SLNet calls and this typically results in multiple inter-process calls being invoked.
In this case, the parameters should have RTDisplay set to true in order to be able to retrieve the parameter value.
Hi Edib, I'll need to provide some additional details to provide an answer to your question: when you do GetLocalElement, you obtain an object that implements both IDmsElement and ILocalElement. Similarly, if you perform a GetTable on an ILocalTable instance, you'll get a LocalTable object (which extends DmsTable) that implements both ILocalTable and IDmsTable.
If you call a method defined in the ILocalTable interface on such a LocalTable object, it will use SLProtocol in the background.
If you use a method defined in IDmsTable, it might still use SLProtocol instead of SLNet. This might be surprising but this is because LocalTable hides some methods that are defined in DmsTable (which it extends). This is the case for the following methods: AddRow(object[]), DeleteRow(string), DeleteRows(IEnumerable<string>) , GetRow(string), RowExists(string) and SetRow(string, object[]).
The GetPrimaryKey method in your example will result in an SLNet call (as it is not hidden by LocalTable). So this call will be the same as you would do it for another element.
I'm not sure if another implementation (e.g. using SLProtocol call to retrieve the primary key and display key columns) would be more performant. It will also depend on the implementation of the table. Also, if you use the displayKey type (ColumnOption@type) then the display key is not available SLProtocol).
Hi Pedro,
string key = protocol.GetLocalElement().GetTable(TablePid).GetPrimaryKey(Message.DisplayKey);
Is this a performant approach for getting PrimaryKey based on DisplayKey from the QAction?