I’m having a problem with the “selection background color” on a table. Here is the scenario: Let’s say the operator has created a table of ten orders in a certain sequence. He then wants to move the order with sequence number 5 to sequence 6. So, he selects Order 5, and it is highlighted with the color assigned in the “selection background color” property. So far so good.
Then, he clicks on a button that increments the sequence number. It moves from 5 to 6, I refresh the table, and the table updates with the new sequence. But, even though the original order is still selected (I bound the “selected row” value to a numeric label so I could trouobleshoot this) the row that orginally contained the order that is moving around is still highlighted with the “selection background color”. To avoid confusion for the operator, it would be nice if the background color always followed the selected row.
Just to be clear, the selected background color does follow the selected row. The selected row is, say, 5. You then run a query that effectively swaps the data in the database in rows 5 and 6. The table is unaware of any meaning that you are infering into the rows. The table maintains the selected row across the refresh - the selected row is still 5. if you want to move the selection, you can do this by manually setting the selected row property.
Thanks Carl. Maybe I’m missing something, but I’m not getting the expected results. Here is what I just tried:
I selected row 5 in my table. A “5” is displayed on the numeric label that is bound to the “selected row” variable. I decremented the sequence number of the order that is in row 5, and then refreshed the table after re-sorting the orders (this is part of the script when I click on the DEC button). The original order has now moved upwards one row in the table, and the “selected row” feedback still displays “5”. But, the highlighted row never moved with order, and Row 3 is the one that is highlighted instead (I clicked on the highlighted row, and the “selected row” feedback changed to 3). When I click on the orginal row, the feedback changes back to 5.
So, in this case the “selected row” had a value of 5, but row 3 had the selected row background color. Is there something else I should be doing in my script?
Ok, I think I understand now. There may be an issue with the order retention/selection retention on the table. I will try to mock this up and get an answer for you when I get back into the office on Monday.
Can you post the code that runs your “move up” and “move down” buttons, or call us so that we can see this over GoToMeeting? I was unable to reproduce this behavior.
Thanks Carl. With your tips, it is now working very well. There is one remaining cosmetic issue though.
You saw my screen, and you can see that there could easily be more rows than are visible on the table. So when I move an order to the end of the list, it disappears off the screen. Do I have access to the scroll bar programatically? I’m not even sure how I would know if the order is moving below the bottom edge of the window.
If the solution is to tell the operators that they will simply have to manually scroll down, that’s ok. But I know they will ask me about it.