We have just implemented an InviewEdit function in a Time Tracking database. Recently, we noticed that when the Save routine is run, the view refreshes when you move your selection to a new document and the view scrolls about three pages up. The selected document is selected, but if you are already scrolled down a couple of pages, you have to scroll back down to get to the selected document.
Please provide any solution possible to resolve this.
Does your editing cause the document that you were editing to be relocated in the view? I’m wondering whether the view is tracking so that the just-edited document is still displayed. If this is what’s happening, there’s perhaps something to be said for leaving it this way. After all, you can always press up-arrow/down-arrow to make the view display the highlighted row, but there’s no key to quickly find the just-edited row.
If you still feel that what’s happening is wrong, please report it to support – it’ll probably be assigned to me to fix, if we decide it’s a bug.
The first column of the view is categorized. This value doesn’t change when the document is edited. the only thing that changes is the editable columns. I have also tried to have the first column sorted instead of categorized and not sorted. same results. The arrow down does work, but I really don’t think the view should scroll like this.
I have found that the issue may be due to the fact that I am using colored background columns. When I removed these, the refresh did not make the document selected scroll out of the screen.
I have seen this as well…very annoying. Yes, removing the alternate row background colors seems to resolves this. Maybe Notes is recalculating which rows are to receive background color?