In this blog post, you discovered the power that shareable entity selections can offer. 4D focuses on data sharing because, in the long run, it leads to performance.
But we’re aware that this strategy might not be your current strategy. We’ve followed the discussions on the forum and understood your comments and feelings.
To soften this step and give you more flexibility and tools, we’ve made some enhancements regarding the nature (shareable or non-shareable) of entity selections.
4D v18 R5 offers more possibilities to handle non-shareable (alterable) entity selections. It helps you work the way you’re used to.
On the other hand, if you’re willing to work with shareable entity selections, we’ve helped you to get prepared for this new era in 4D v18 R5. In 4D v18, we’ve introduced a flexible way that you can use transparently to prepare your code.
In a nutshell: prepare in 4D v18, run in 4D v18 R5, and get ready for more performance!
about alterable entity selections
add an entity to an entity selection
A frequent use case is displaying an entity selection in a list box (products, invoices, etc.) and allow the user to add new ones.
Let’s work on a Products dataclass.
When the form is loaded, Form.products is created, it’s the datasource of the list box:
: (Form event code=On Load)
When the user adds a new product:
We’re aware of this inconvenience. That’s why you’ll find that the 4D v18 copy() function is available to prepare your code to get ready for 4D v18 R5.
If copy() is run in 4D v18: it just copies your entity selection
If copy() is run in 4Dv18 R5, by default, it copies your non-alterable entity selection as an alterable one so that you’ll get no problem with the add action!
So just prepare your code like this:
: (Form event code=On Load)
retain the nature of entity selections
Entity selections created from an original entity selection keep the same nature.
Sort a list box
Let’s work again on the example of displayed products. This displayed entity selection has been set as alterable because the user needs to add new products.
Any sort of action on the list box columns keeps the alterable nature of the entity selection so that you can still add products.
Run a query
If you run a query on an entity selection, the nature of the entity selection is kept for the result.
In our example, if the user runs a search on the displayed products:
Form.products:=Form.products.query("name = :1"; Form.search)
The result of the query is alterable so new products can still be added because Form.products is alterable.
These are only two examples. Check the documentation to verify all of the cases where the nature of the original selection is kept.
It can be useful to check the nature of an entity selection in generic code in order to use it in the appropriate way. Imagine a method receiving an entity selection that can be either shareable or not.
In the example below, we receive a Products entity selection. Before passing it to a WORKER, we must check to see if it is shareable. If it’s not, we turn it into a shareable entity selection.
For this, we use the new OB Is shared() function.
var $products; $1 : cs.ProductsSelection
If (Not(OB Is shared($products)))
//Generate the catalog of products
CALL WORKER("worker"; "buildCatalog"; $products; Current form window)
Note: There is also a new isAlterable() function available on entity selections to check if they are alterable.
Download the HDI above for more examples!
Keep working as before
If you want to continue the behavior of previous 4D versions (without any concepts of shareable entity selections), you can use the makeSelectionsAlterable() class function available on the datastore object.
This will make the changes brought with 4D v18 R5 completely transparent for you.