Welcome to the Birder's Diary Forum for Support And General Questions
Use the Support forum for all questions or issues.
Use the Wish List forum to leave your ideas for improving Birder’s Diary.
Use the Community Sharing forum for sharing Photos, Trips, Stories, etc.
Setup your Forum photo and profile here.
[Solved] Rows scroll up
The one thing I am trying to avoid is empty rows at the bottom of the grid after Edit when there are rows to show if I scrolled up the list. This was the original issue unless I am mistaken.
However, this is just an endless circle. This 3rd party grid has so many bugs in this respect. So, starting with the next Build release (11), all that the code does is to make sure the edited row is visible, with no blank rows at the bottom, when there are rows to show if you scroll up. It is endlessly complicated.
Build 11 with this new simplified functionality has just been released. fyi
Great. But I found that if I make the window smaller so there is not blank space below the rows, things do not scroll up. That may have been the trick. In an earlier build, maybe the window was sized correctly if there are not enough rows to fill the window.
I was editing sightings to change a comment. One entry was on the first page of the grid (No Scrolling to find it). I made the change and the entry did not scroll.
I scrolled down until I found the next sighting that I wanted to change.
I edited the sighting and the entry scrolled to the last row of the window after editing.
So, it seems like only the grid on the initial window is free of the unwanted scroll. If I scroll down to a sighting and then edit it, it will scroll to the last row of the window after editing.
Using BD V6 build 11.
PS: I liked it better when it scrolled up
Regards, Al Borodayko
Thanks for posting. I have spent endless...ENDLESS hours since v3.0 on this issue. The 3rd party grid being used here is full of bugs wherein this is concerned.
After spending probably 40-80 hours on this recently as attested to above I have settled on the current, very basic, scheme. Which is, just make sure the previously last selected row is visible after the grid refresh. I stated this above previously. This is simply an intractable problem. If I do as you say above, and try to get it to work the other way, many other issues then arise; and any attempt to resolve those only results in a whole other set of new issues. It's an endless circle.
I think we just have to stay with the current functionality. It is not what I would prefer either, and it has driven me nuts over the years. But I simply have to know when I am beat; and on this one, I AM BEAT! I surrender. LOL.
After refresh, in the first page of the grid, the entry is visible.
However, in the second scenario where I scroll down to find an entry and edit it. Then I do a refresh, the grid returns to the first page (slide bar returns to the very top) making the selected row no longer visible.
No problem if you can't fix it. I very rarely experience that scenario.
Here is how my program behaves. I added xxxx to a comment for a Canada Goose as a test.
Canada Goose 1 - The selected entry located beyond the first page. Note position of scroll bar on the side.
Canada Goose 2 - The selected entry after editing scrolled to the bottom.
Canada Goose 3 - The sightings returned to the first page after clicking on "Refresh Query" (rotating arrows in the upper left corner).
Canada Goose 4 - The selected edited entry after scrolling down to find it. Note: It was no longer highlighted. Don't know if it should stay highlighted.
My page setup is in the Maximized mode for the basic screen. The view and edit screen is in the Restored Down mode and edges dragged to fill the space.
Regards Al Borodayko
Ah! Thanks for clarifying Al. You probably said this before, but I think we were talking about 2 different things concerning 'Refresh'. I was talking about the Refresh that occurs after editing automatically (where the edited record is always shown somewhere on the visible grid).
You are talking about the Refresh that occurs after manually clicking the Refresh button. The Refresh button will lose all context. It is intended to act as Refresh as if you are just coming to this page for the first time. Perform the query anew and using the criteria and sorting specified in the Setup window initially.
There is no need to manually click the Refresh button after editing a sighting. The list has been refreshed but current sort changes (e.g. clicking on a column header to sort by that column as opposed to what was specified in the Setup window) are preserved and the previously selected/edited row is still selected and visible somewhere in the visible portion of the grid.
Does this help explain your situation?
I get it, Al