Hi, I’m trying to figure out if there is a way to navigate between rows in a database using buttons on a window. Below is an example of what it looks like. The idea is that the data in the row is shown in the middle and the Next button will navigate to the row below the one that is currently showing while the Previous button will navigate to the row above the one that is currently showing.
For example, I have three rows, row 1 displays AB0123, row 2 displays AB1234, and row 3 displays AB2345. Row 2, or AB1234 is currently showing, but I want to show Row 3, or AB2345, so I press the next button and AB2345 is then displayed in the middle. Same process for the previous button. Any suggestions on how to go about this?
how do you determine where to start? does your table have a ID column?
It’s going to have to be a process like:
- Open Ignition window
- Get the “smallest” element in the table (or have the last accessed elements saved somewhere)
- Get the “largest” element that is smaller than your current element. This is the element that your “Left” button will access
- Get the "smallest’ element that is larger than your current element. That is the element that your “Right” button will access
- When “left” or “Right” is pressed, get the data from that element
- GoTo #2 and start all over again.
That’s the basic idea, which is basically traversing a linked list that is stored in the DB. However the performance is is going to depend on how many rows are in your table and whether or not the element column is indexed.
If the number of rows is not large then you could just pull a sorted list of elements into an array structure, and just jump around with array indices.
You could possibly also do this with cursors in the DB itself, but that’s definitely an advanced topic. But if you already know that your element data is monotonic, then this actually makes things easier - you are just accessing the row before and after the current row.
Or you could even run query in the DB that scans all your rows and builds a mapping table of previous and next elements. Such a table would have be updated each time you inserted or deleted an element into the main table. That could easily be optimized to only look for changes caused by the element that was inserted or deleted.