If I were solving this exact use case, I’d go one of 2 ways:
Non-widget method
In this way, you’ll know via the helper object what the user has currently selected, and can use that in a “Select All” button to retrieve the same.
Widget method
Edit:
Most widgets in the app store (if you access it from a browser) have a link to a GitHub repository. In the repo, you'll usually find a test project as well as build tooling to pack the widget code into an mpk. So, fork the ListViewControls widget repo, clone a copy to your local machine. In the case of ListViewControls, you'll find that the widget is built in TypeScript and uses React inside of a Dojo wrapper. Unfortunately this makes it a bit complex to edit for someone new to the frameworks involved.
On a bright note, I just made an edit to the widget that's actually very similar to what you need to do. In my case, I was modifying the HeaderSort widget to require a context entity, and to enable a dynamic label on that header. See that commit detail here. I hope you can try making similar edits on your fork to help you figure out how it works.
Once you have a local clone of your repository, run 'npm install' on the directory. Then you’ll be able to run commands like ‘npm run build’ to create a production-level mpk or ‘npm run dev’ to set up a listener that rebuilds your widget every time you edit the widget files and save. This listener injects the code into the local test project (see the test directory) so that you can open the project in the modeler, run it, and then edit/debug your widget on the fly.
I realize this is a total crash course but hopefully you’re up for a challenge. Mendix does offer a widget workshop training course via Expert Services in case you’re looking for a more structured approach.
You can use the context object or query for the widget by id/node using dijit.byNode or dijit.byId, share the data, and call update