You will need to "maintain" the record ID if you want to write back any changes to your sqlite DB.
Does your table have to fit the screen, or can it scroll horizontally to view more columns? I assume it will also be OK for your table to scroll vertically....
I set some source data which should represent the query output from sqlite, including the record id. This is needed for writing back an updated record, or deleting a record from the sqlite table. I have not handled this part, but include procedures where additional sqlite blocks can be used.
the source data is tidied up for the table data, removing the id and adding the two icons for each row
I used emojis for the edit and delete icons. It is possible to also use images from local or url sources
You can do more editing to the table format to remove borders as required
I have written code for the Tableviewer click event, so that only the icons generate a response
You can improve the formatting for the edit/update dialog if you wish
This table fits the screen on my phone horizontally, and it will scroll vertically if many more records are added, beyond the height of the screen. You can add further formatting to the table to get a sticky header row.
You can have a choice with this one. Would you prefer to edit a record in place in the displayed list, or do as I have done for Tableviewer and open a dialog?
Here you are with an aia project example of using CompCreator (credits @Kevinkun !) to generate a displayed table that allows editing of a record or the deletion of a record
The table is set in a vertical scrolling arrangement, so should scroll when more records than the height of the screen are added. On my phone the table fits well horizontally.
The blocks look complicated at first, but once you get the hang of how to create components, and then more components inside components, and then format components either individually or collectively, then it starts to make sense
I create the vertical scrolling arrangement "outer", then add a horizontal arrangement, for the header, then for each record. Inside these I set three textboxes (only four labels for the header) and two buttons. For the buttons I also generate a list of the edit buttons and the delete buttons. The indexes of these two lists are used to run actions (edit/update or delete) on the tableData list, after which the table is redrawn with the new data. The record ID from the sourceData table is also captured.
With this example, when you press on an Edit icon (pencil), it makes the three items in that row editable, just like you see with AI2 textboxes. The pencil icon is changed to an "OK" symbol. To make changes, or cancel out, the "OK" symbol must be pressed, to offer the user options of either updating or canceling.
This example uses javascript to make the table cells editable (or not), and to return the edited values.
The record ID (rowID) is returned in a variable, as in the other examples.
More work can be done to rationalise the blocks, I did much of it "longhand" which may make it easier to see what is going on.
You can only edit one row at a time, the blocks programming prevents editing multiple rows at once (by accident, not by design !).
This comes with a sample db in the assets, which is copied to the ASD on first run, and set as the default database. (Backup up your database if you already have one in companion app, as this will be overwritten)
Thank you very much for your help and time to create a solution. In fact I was trying to do myself a way to insert a record on the table, based on your previous posts about TableViewer. But now I'm going to apply those ideas to my app. It's not necessary filter or other things like this.
