Entity selections between processes

So i have spent a few hours failing.
Am i right that there are no way to send entity selections between processes? I have no problems to send collections or regular objects but with entity selections it seems they really don’t like to be passed between processes. Been trying both with regular parameter passing and with CALL WORKER/CALL FORM.

Shared objects don’t seem to like the “object” of an entity selection either. (wrong valuetype or something)

So why do i want shared entity selections? I am not sure. Do i really? I thought it was a neat way to create an asynchronous search on data that could possibly create fairly large selections.

But my question is. Is it possible?

I’m not sure that makes sense. The server load is the same, it needs to find the records.
You start a query, and that query is running on the server and doing the job.

If you build the collection with your own code, consider using query by formula instead.

So far there is no difference between ORDA or classic language, about “passing” a selection between processes.
In classic, you used a longint array containing record numbers (also known as “named selection” for sorted selections, or “set” (boolean array) for unsorted selections).
In ORDA, you use a collection of primary keys.
But you pass that collection of primary keys to another process.

Still I do not really see why using another process, but if you need, pass PK collection

Thank you Thomas. That was the information i was looking for.

The paradigm of looking at selections and records just as any object is very powerful. But as usual one need to know its limitations. Maybe this could be highlighted somewhere in the manuals in the future? The creature of the entity selection “object” is so damn powerful. Its just when you realise its not an object but an entity selection.

: Thomas MAUL

Still I do not really see why using another process, but if you need,
pass PK collection

There are a lot of use cases. For example, pass a selection to another process for display. Pass a selection to a server or worker process to generate a report. Lots of uses for sets and named selections that are now less convenient with entity selections. Of course, as you say, we can all write our own code to convert from an entity selection to some other representation and then convert it back to an entity selection in the receiving process.

Yes, 4D could optimise speed, because you cannot easily take over the sort direction (you always have to use orderByFormula), which is very slow with a lot of records.

However, keep in mind, that entitySelections may have different states in different processes, if you are using transactions, some records are not “seen” from other processes and vice versa.

I already posted a feature request, that 4D “creates” a new entity/entitySelection for new processes (and with the right sort-order).

: John DESOI

pass a selection to another process for display.

in the past, when each process could only have 1 current selection, that made sense.
now that a process can maintain many entitySelections, and a process can run many dialogs,
is it really necessary to start a new process “for display”?

in theory, 4D only needs 1 process for the UI, the application process (#1), another process for printing, and then more processes and workers for tasks without a UI (network, import/export, etc).

Thats why my initial design. Trying to rethink the management of data and trying out tactics to handle preemptive solutions. Having an idea to at least split the selection of data with the user interface. Thats why it seems “unnecessary” to create a complex search and one process and not beeing able in an efficient way to send the live result of that query to another process. Especially as we now have the possibility send entity selections as parameters to methods in the same process.

At the same time entity selections are so damn powerful. Selection of data have never been this easy and advanced. So for me it seems like a waste of opportunities not to use entity selections in the user interface too.

If thats a problem in 4D then thats OK. It just took me to long to figure out and i really tried to find anything about it in the manuals.

: Keisuke MIYAKO

in the past, when each process could only have 1 current selection,
that made sense.
now that a process can maintain many entitySelections, and a process
can run many dialogs,
is it really necessary to start a new process “for display”?

That might work if you have a new application or small application to convert. I have many years of code and hundreds of input forms that use records. Making all of those forms work in one process would require rewriting numerous working input forms to avoid conflicts in record selections.

The good news is you can change from selection list boxes to entity selection list boxes for the selection display (output form) and still keep a record model for legacy forms.

: Christian SAKOWSKI

Yes, 4D could optimise speed, because you cannot easily take over the
sort direction (you always have to use orderByFormula), which is very
slow with a lot of records.

To transfer an entity selection to another process, I use a named selection (if ordered) or a set created after USE ENTITY SELECTION. If 4D would add an optional selection name to USE ENTITY SELECTION, that alone would be a helpful improvement.

Hi John,
I’m used to work with ARRAY LONGINT ARRAY FROM SELECTION/CREATE SELECTION FROM ARRAY instead of named selection. Both accept a temp selection as parameter.

Hi Arnaud,

That is what I was hinting at. To get an ordered selection from an entity selection to pass to another process I currently use:

<code 4D>
USE ENTITY SELECTION($selection)
CUT NAMED SELECTION([Table];“selection”)

</code 4D>

It would be nice to just have
<code 4D>
USE ENTITY SELECTION($selection;“selection”)

</code 4D>

It only saves one line of code, but I assume it would save a second server call and some selection management.