Hello @Ayushi Kumari,

This tutorial might help you: 

How to add select and select all checkboxes to tables in OutSystems?

Hello @Ayushi Kumari 

You can archive this by checking the tutorial above that Sherif shared, you only need to take care if thre is pagination and you are selecting all and you wan to delete all data not just paginated 10 row so  you  need to write another logic that if we select select all checkbox and we are goind to delete so inside server action write logic to delete all data not just data that is available on screen

Hi @Ayushi Kumari 

You can see this in the behavior below:

Because the screen is using pagination, the Aggregate’s Max Records is limited to 10. So when you click “Select All”, it only selects the 10 records currently loaded on that page.

The Aggregate only loads the next set of records when you move to the next page. If you want “Select All” to work across all pages, the Aggregate must fetch all records upfront. To do that, set Max Records to a value larger than the total number of records in your dataset.

Hope this helps

Peter Hieu

Hi @Ayushi Kumari ,

Checkboxes are very attractive and cute, but you get yourself into a whole world of problems to solve if you go this way.  Don't solve them properly, and your application will be buggy / weird to use.

0) don't allow to paginate, sort or filter in combination with checkboxes

That is easy.  In that case, what the user sees is what he gets.  For example, by fetching everything, but that's only feasible on very small datasets (like maybe a small list of offices that your company has, or a small list of subcontractors)  What you want to do is not entirely clear from your question, but since you mention pagination, this is not the case you are in.  

In other cases, don't retrieve everything (max records very high) just to support checkboxes.  I personally think combining checkboxes with large datasets, is problematic, and maybe check with your business if they really need it.  

If you allow selection on larger datasets, the easiest is to force them to work by page, as soon as they start selecting, don't allow them to paginate / sort / filter until they have processed or unselected everything.

1) combining selection with pagination

This has nothing at all to do with whether you also have a select all option.  As soon as you allow users to check certain rows for later processing, and you allow them to also navigate across pages to do so, you will have to devise a way of remembering what was selected on each page.  

So, when selecting/deselecting, you will have to maintain that memory (for example a local list of the id's of all items selected)  Add/remove the current one.

And, when fetching another page, you will have to check that memory to know if your aggregate should return an IsSelected of True or False for any given record fetched.  (for example, incorporate an Index into your local list on the aggregate filter).

When actually doing something with the selection, you can use that local list as the thing to iterate the execution.  (don't iterate it at the client side, though, pass it as a list to the server side and iterate there)

2) adding the option of select all

This one doesn't actually add that much functional difficulty on top of 1).  All you need is a local variable that represents whether to select all or not.  In your aggregate, when Select all is on, you can return all of them as IsSelected True.  In your ultimate processing, you can pass in that SelectAll variable as input to the server, and when on, process all of them.

The Select all does give you a lot of extra presentational headache about how to keep the individual checkboxes and the select all checkbox aligned with each other. The vanilla examples are easy, after retrieving the list, flicking it on selects everything, so you set each individual checkbox as selected.  After that, flicking it off again deselects everything, so you set each individual checkbox as deselected.  But the though part is, how do you combine the select all value with actions of users on the individual rows, for example, what value do you give the SelectAll if, if some are selected and some are not ?  

In a sophisticated solution, I think the 'Select All' variable should not be a boolean, but a trilean, but that will bring us too far here.

3) what about sorting and filtering

If you have that local 'memory' and/or the local 'select all' variable, you could technically allow them to sort and filter, that won't change much for your logic.  And I think sorting doesn't pose much presentational problems, it could even help the user experience by allowing them to sort on the checkbox column (gathering all the selected ones for a better overview)

But I think combining with filtering is where you could start confusing your users.  For example, if you can change the filtering at any time during selecting, what does the 'select all' mean in this context, select all that fit the filter OR select all in the database.  That is something you need to make clear (by maybe a hover text on the select all widget)  

Also, if they have applied several filters after each other, and on each of those filters, have selected a couple of items, how can they maintain overview of what is selected.  If I would allow this, I think I would always show the selected, even if they don't fit the current filter.  I would also make them visually different.  Like set them on top of the list and grayed out.  That way, they can still unselect it at any time, without having to first go back to the previous filter.

Dorine

Hi Ayushi,

When you use pagination in a Table/List widget, only the records on the current page are loaded into the UI. So if you just bind a checkbox directly to the table values, OutSystems will lose the selected checkboxes when you navigate to another page.

To correctly maintain the selection, you must persist the selected state yourself.