[Solved] Rows scroll up

Hi David,

This 3rd party Grid control, how it scrolls and repositions has been a pain in my side for 20+ years. I have made attempts at getting it to perform more intuitively in various situations, but only manage to make a little headway.

The key here is the exact situation you are in. The grid repositions differently depending on these variables. Please let me know your situation so I can attempt to reproduce.

• How many rows are in the grid when you are editing a sighting?
• What is the position of the row you are going to edit before you edit it?
• After editing, you say the row becomes the second row on the screen. How many rows contain data below this row?

Posted by: @magmatic

I hit refresh the rows scroll down again so that I can now see all of the rows in the window. Or I can use the scroll bar. Of course, this does not happen for the first two rows.

I don't follow this very well.

"...rows scroll down again..."?

"...all the rows..."

Do you have Greenshot? It is an excellent FREE screen capture tool. You can capture rectangular areas of the screen to the Clipboard and Paste them directly into your post here. It is always running on your computer and activated via pressing the PrntScn button on your keyboard. Or you can use Windows default screen capture utilities. You can obfuscate areas of your capture that might contain sensitive info before you post it in here.

The point being, is that it would be easier to follow along on these stories if you show before and after pics at each step. Also saves you a lot of typing. 

Could I get you to try that out and post back here showing this story in screen captures? These situations are so situation-specific that, without these kinds of details, it's like chasing a rabbit in the dark.

Thanks. 

Here is a set of sightings.

If I edit the last row. Update it. Suddenly the screen looks like this. The row I edited is the second row on the screen. The rows above that are hidden.

I can move the vertical scroll bar up to see all of the rows again. So it looks like the first picture again.

Thanks for the pics David. I can now reproduce, and was able to work on this issue for mucho hours (I need a life). As usual, my brain hurts now. This problem is intractable; much harder than a first glance can possibly appreciate.

I have come to realize that it is why the makers of the Grid control itself don't have solutions to this.

The number of scenarios and different use cases is large. 

You have one of the simple ones wherein you are editing a single sighting and the change does not affect its position in the current sort order when the grid is refreshed.

I think I have a much better solution after working on this for many hours. I like these kinds of challenges - apparently.

Going to play with it a few more hours this weekend to make sure I don't create a bigger problem than I am trying to solve. Then hopefully, I will have a new release for this that does a better job for 98% of the cases.

Stay tuned.

Hmmm. I wonder what changed between 5.3 and 6.0. It worked fine in 5.3. I wonder if others are experiencing this. But you don't have to spend the weekend. There is an easy workaround for now. Just hit the refresh button.

Hello jeff,

I just edited a sightings entry that was near the bottom of the grid. After, update, the grid scrolled up and the edited entry was the second row from the top. Using BD V6 Build 9.

More evidence, Al Borodayko

Cypress, CA

Posted by: @aldeboro

I just edited a sightings entry that was near the bottom of the grid. After, update, the grid scrolled up and the edited entry was the second row from the top. Using BD V6 Build 9.

More evidence, Al Borodayko

Hi Al,

Yes, for sure. This has been the case in that scenario for a couple years now.

I have made changes attempting to improve how this works in > 98% of all situations, but have come up short; more like 75%.

But now, I believe I have found a solution that works in the 12 different scenarios I have been testing in.

• Rule 1: the current row (the one with the rubber band around it; not necessarily the highlighted row) should always be visible on a refresh.
  Even if editing the records changed the display order for some reason. When editing records, you must select at least one row; so in this case, the last or only selected record will generally be the current row. But the user could arrow up or down and change this without changing the selected records.
• Rule 2: the current row should remain in the same position in the grid if the order of the records has not changed after edit.
• Rule 3: if the order has changed, then...
  • 3a. position that record in the grid on refresh to the same position as before the edit (e.g. 4th row from the top), unless
  • 3b. doing so is not possible...
    • 3a1. It is near the top and you cannot scroll the grid down to put it, for example, on the 10th row.
    • 3a2. It is near the bottom and you don't want to show empty space in the grid, so scroll the grid up until all rows are occupied. The case in this topic.

Yup, and that doesn't even begin to capture all the caveats and scenarios, but this is what I am attempting to do with the new code; and so far, it is working on the 12 scenarios I have for testing.

Now, throw in editing more than one record (e.g. 8 different rows) versus just one record; and what if those records are not contiguous; and what if one or more of those records changed position in the relative order after editing. Where should the grid be positioned? See the Rules above.

It's a game of chess. And I do agonize over every single one of these details in BD, and always have. I don't always get it right, but I generally progress towards better than before when I am reminded of a scenario that is less than optimum.

I wonder how long that code will be used before someone finds scenario #13 that I didn't forsee. 😎 

Have a great weekend. Hopefully I finish this code by Monday.

GACK! I found scenario 13. 😪 😫 

Ok - 1 week and 80 hours later; a few tears shed... 😓 and Build 10 is now ready.

This code fixes the above mentioned less-than-desirable functionality when editing a record near the bottom. It also addresses many other scenarios that I have documented throughout the years (about 14 scenarios).

I can't promise that I didn't break a few things or that this catches everything. This 3rd party Grid control is so very buggy and always has been in this particular respect - the ability to position the grid exactly where you want it, and where it makes the most sense.

Build 10 is available without the normal announcement. Just for those with this issue as it doesn't affect most users in day-2-day work.

Let me know. Marking as solved - but possibly more broken! 😎 

I tried editing a row with build 10. Still bad. But instead of scrolling up to the second row from the top, it scrolls up to the top row.

Ok - scenario #14. Number of populate rows in grid is less than height of grid. Is this your scenario?

It doesn't matter how many rows are on the grid. 2 rows or more gives the result. The edited row jumps to be the first row visible.

If I select multiple rows, it is the last row in the edited group that jumps to the top.

It doesn't matter what position the row is in. Second row or last row, it jumps to the top.

By #14 I think you mean there are so many rows that you have to scroll to see all of them. In that case, I scrolled down to the middle of the group and selected a row in the middle of the screen. After editing, it STAYED WHERE IT WAS. It did not jump to the top. The same happened if it is a row near the top of the group (did not have to scroll down to see it.)