@Functions can be used using "Evaluate" LotusScript method.
https://help.hcl-software.com/dom_designer/14.0.0/basic/H_EVALUATE_METHOD_SESSION_COM.html
However, the documentation of "Evaluate" method clearly says that -->
The formula takes the field from the specified document.
@Functions that affect the user interface do not work in the Evaluate method. These include: @Command, @DbManager, @DbName, @DbTitle, @DDEExecute, @DDEInitiate, @DDEPoke, @DDETerminate, @DialogBox, @PickList, @PostedCommand, @Prompt, and @ViewTitle.
The requirement is to use @Picklist using "Evaluate" or some other ways in LotusScript.
@Picklist does have a LotusScript alternative with name as "PickListStrings".
However, while using @Picklist with "Name" argument, the results are not similar as that appearing with "PickListStrings".
Ex --> @PickList([Name];FieldName)
and ws.PickListStrings(PICKLIST_NAMES , True) doesnot return same content.
So, we might need some other LotusScript method that can work exactly like @PickList in case it cannot be used with "Evaluate" method.
See the attached screenshot for better understanding.
I propose changing the subject of the current idea to "Unification of @Picklist and PickListStrings".
By the way, the PickListStrings method has the same disadvantage - it is impossible to specify the server from which to open the address book.
It would also be great to be able to specify the optional database parameter in both functions to open a dialog from your own directories, and not from the address book.
The request subject is incorrect. @Picklist should not be performed using Evaluate!
There are disadvantages to both functions. And improvements to both functions are long overdue.
The disadvantage of the PickListStrings method is that you cannot pass an array of values that you already have. And this is very inconvenient! An additional optional parameter is needed to pass an array of existing values.
The disadvantage of the @PickList ([NAME], [ROOM], [RESOURCE]) function is that it displays data from a single (static) address book. We work on different environments simultaneously, in which the contents of address books are very different or completely mismatched. It's also very inconvenient. Adding the optional sever parameter is very necessary for choosing which server to open the address book from.
As a result of this unification, it is expected that PickListStrings and @PickList will work the same. The appearance is needed like @PickList, with a right panel.