onCellClicked returns correct cellView but incorrect row after sorting about tableview

[alanjshort]

If a grid has a small number of rows, this bug is present. If the number of rows is larger, the bug disappears. Not sure exact number of records to make bug disappear (but it's more than the visible grid).

If you sort a grid on any column, following the sort, click on a cell, the onCellClicked event returns correct cell view, but the row returned is the unsorted row number. This means that if you highlight based upon the returned row using setSelectedRow(row), the wrong row is highlighted, though the correct cell data has been returned.

public void onCellClicked(@nonnull RecyclerView.ViewHolder cellView, int column, int row) {
try {
mTableView.getSelectionHandler().clearSelection();
String strData = "";
if(cellView instanceof CellViewHolder){
strData = (String) ((CellViewHolder)cellView).cell_textview.getText();
}
mTableView.setSelectedRow(row);

          // processing of strData 

    } catch (Exception e) {
            e.printStackTrace();
    }

Tableview Version '0.8.9.4'
Android Version 9

[samanta-widjaja]

this happen when i filter the table too.

[alanjshort]

Yes - it's so buggy that you spend a week putting it all together and a month creating crazy workarounds. I first tried to use it a couple of years ago but abandoned it because of the bugs, but for a current project, I've actually delivered a working solution! Once you find your way around your current problems, you'll discover the slippage when you scroll; the grid will visually break up on you if you allow the cell widths to expand to accommodate your data. Don't despair - instead, have the cells already at maximum width. An easy way to do this is to fill the column headers with trailing spaces so that the cells are already as wide as they need to be. Remember that with non fixed width characters, you'll need a lot more spaces than if you filled it up with Ws. You'll work it out. There is unfortunately nothing else out there. Oh for those simpler days when we all worked with WinMobile. So much better than Android in every way, but as the song goes, "Progress runs it's driven course and tractors have replaced the horse."

…

On Mon, Nov 22, 2021 at 8:13 PM samanta-widjaja ***@***.***> wrote: this happen when i filter the table too. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#396 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANYKRQZW2LONLMZEL6FDMS3UNLTDTANCNFSM5IACPIXQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

-- Regards Alan J. Short

[alanjshort]

But in answer to your frustration about sorting, my solution was to never ever use the sort functionality of this horrible 'work in progress'. Instead, I created a function that passes the query, number of rows and an array of column names, to refresh the grid. Whenever a cell is clicked, I pass the value of column zero of that clicked row through a record in a database, then monitor that record in a timing loop on the main thread. I do a similar thing for column headers, and whenever a column header is clicked, I then generate a new query with an ORDER BY based upon the column that was clicked. Ugly as sin, but works. Oh, and I arrange all the columns so that key values are at the beginning of the rows, even if the grid is scrolled (e.g. custID, custName, custAddress etc.) so that even at maximum scroll, the first visible column is still a unique identifier, then when I get a value back, I check for a match with (in this example) custID, custName or custAddress. And all because the bloody Android GridView is so limited, and nobody can work out how to use the recycleViewer without resorting to the evrancoskun 'solution'. It's a disgrace.

…

On Mon, Nov 22, 2021 at 10:37 PM Alan Short ***@***.***> wrote: Yes - it's so buggy that you spend a week putting it all together and a month creating crazy workarounds. I first tried to use it a couple of years ago but abandoned it because of the bugs, but for a current project, I've actually delivered a working solution! Once you find your way around your current problems, you'll discover the slippage when you scroll; the grid will visually break up on you if you allow the cell widths to expand to accommodate your data. Don't despair - instead, have the cells already at maximum width. An easy way to do this is to fill the column headers with trailing spaces so that the cells are already as wide as they need to be. Remember that with non fixed width characters, you'll need a lot more spaces than if you filled it up with Ws. You'll work it out. There is unfortunately nothing else out there. Oh for those simpler days when we all worked with WinMobile. So much better than Android in every way, but as the song goes, "Progress runs it's driven course and tractors have replaced the horse." On Mon, Nov 22, 2021 at 8:13 PM samanta-widjaja ***@***.***> wrote: > this happen when i filter the table too. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#396 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ANYKRQZW2LONLMZEL6FDMS3UNLTDTANCNFSM5IACPIXQ> > . > Triage notifications on the go with GitHub Mobile for iOS > <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> > or Android > <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. > > -- Regards Alan J. Short

-- Regards Alan J. Short