Bug 7282

dw.ScrollNextRow() can cause rows to jump rather that scroll by one row 29 September, 2021

Dan Cooperstock
21 September, 2021
Product: PowerBuilder Category: DataWindow
Version: 2019 Build: 2082
Classification: Issue Publishing: Public
Priority: P3
Status: Closed Reason: RESOLVED
Mark Lee @Appeon 29 September, 2021
#8
Hi Dan,

Thanks for your understanding. 
I will now close this ticket and please feel free to open a new one if you encounter any new issues.

Regards,
Mark Lee
Dan Cooperstock 29 September, 2021
#7
(In reply to Mark Lee @Appeon from comment #6)
Hi Dan,

Do you have a chance to try the case I provided in comment 4? If you want it
to always scroll up by one row, you can just disable the group
functionality. If you need to use the group functionality, then it is its
limitation, not a bug. You can refer to the link below for details.
https://docs.appeon.com/pb2021/pbug/ch06s06.html#Grouping_rows 
Scrolling through a grouped DataWindow
When you scroll through a grouped DataWindow object, you might see the group
header repeated where you do not expect it. This is because the data is
paginated in a fixed layout based on the size of the DataWindow control. You
can scroll to a point that shows the bottom half of one page and the top of
the next. When you use the arrow keys to page through the data, you scroll
one row at a time.
 
As for another problem, we don't have a better solution for you. As I
mentioned before, it is out of the scope of our Standard Support policy.
Hope you can understand.

If you don't have other questions, we will close this ticket.
I don't have the DW in print preview mode, so no paging is occurring, and no behaviour like you are describing here. If I scroll by clicking the arrow keys at the top and bottom of the scrollbar, it always scrolls by exactly one row at a time. It still seems very reasonable to me that the ScrollNextRow and ScrollPriorRow functions ought to behave exactly like those clicks behave - but they don't. So we are going to have to agree to disagree on whether your current behaviour is reasonable. So go ahead and close this case.
Mark Lee @Appeon 29 September, 2021
#6
Hi Dan,

Do you have a chance to try the case I provided in comment 4? If you want it to always scroll up by one row, you can just disable the group functionality. If you need to use the group functionality, then it is its limitation, not a bug. You can refer to the link below for details.
https://docs.appeon.com/pb2021/pbug/ch06s06.html#Grouping_rows 
Scrolling through a grouped DataWindow
When you scroll through a grouped DataWindow object, you might see the group header repeated where you do not expect it. This is because the data is paginated in a fixed layout based on the size of the DataWindow control. You can scroll to a point that shows the bottom half of one page and the top of the next. When you use the arrow keys to page through the data, you scroll one row at a time.
 
As for another problem, we don't have a better solution for you. As I mentioned before, it is out of the scope of our Standard Support policy. Hope you can understand.

If you don't have other questions, we will close this ticket.
Dan Cooperstock 24 September, 2021
#5
I'm sorry, but I don't find that to be a very satisfactory response. I really think it is not unreasonable to expect the behaviour of a method called ScrollNextRow to scroll up just enough to display the next row, rather than the current behaviour, which is (at least if there are group breaks) to scroll up to some arbitrary position, in which the next row that wasn't previously displayed is displayed. (Obviously, the opposite behaviour should work for ScrollPriorRow.)

Along with the argument based on reasonable expectations of the meaning, it also means that there is no way using the Scroll* methods to achieve what seemed to me to be a very reasonable desired result: if there enough rows, to be able to position a given row as the first (or last) displayed row in a DW. The only way I was able to reliably do that is in the Q&A thread I linked to earlier, using the VerticalScrollPosition, which is a much less obvious and indirect way to do it.
Mark Lee @Appeon 24 September, 2021
#4
new datawindow

Hi Dan,

Thanks for providing the test case.
I can reproduce it on our side, but I think this is a normal PB behavior because the previous PB versions all behavior like this.
It is due to that you enable the Group functionality in DataWindow, which results in automatic paging. If you don't want it to jump to put the next row at the top rather than scrolls up by one row, you can check the 'New Page on Group Break' functionality of the Group properties (see the attachment).
 
And I also don't think this Help is vague, when removing the group functionality in your datawindow, the current behavior is as what it says in the Help documentation: "After you call ScrollNextRow, the row after the current row becomes the new current row. If that row is already visible, the displayed rows do not change. If it is not visible, the displayed rows move up to display the row."
 
For the differences if you use the Group functionality, we will discuss it internally and see if we need to add it to the Help 'if there is group functionality set in DataWindow, during paging process, after you call ScrollNextRow, it jumps to put the next row at the top rather than scrolls up by one row'

Regards,
Mark Lee
Dan Cooperstock 22 September, 2021
#3
scrolltest.pbl (45KB)

Sorry it seemed to ignore my attachment! Trying again.
Dan Cooperstock 22 September, 2021
#2
scrolltest.pbt (0KB)

OK, it seems it happens when there is a group break with a group header. Run the attached application, hit Scroll Next Row 3 times, you will see how it jumps to put the next row at the top rather than scrolls up by one row.
Mark Lee @Appeon 22 September, 2021
#1
Hi Dan,

Thanks for reporting this problem.
For the issue "If you are on the bottom row of a DW and call dw.ScrollNextRow(), it can jump that next row up to immediately be the middle row of the DW", I built a small sample test case but can't reproduce it on our side. 
Are there any special settings in your case? Please provide a reproducible sample test case (including PBT/PBL) for us to reproduce on our side! Thanks in advance.
 
For the question you asked in the forum, do you mean the ScrollToRow function has the same bug as ScrollNextRow?
 
Please note that this is a standard support ticket and we only handle Appeon bugs or requirements on a standard support ticket. If you want to consult how to use some functionalities, you should use Premium Support because it is out of the scope of our Standard Support policy (https://www.appeon.com/appeon-standard-support-plan.html).
We would be happy to offer your organization a complimentary Premium Support ticket to try out our service.  Please contact our Sales Dept. via email at sales@appeon.com to obtain your ticket.
After you receive your complimentary Premium Support ticket, please transfer this ticket following this guide (https://www.appeon.com/developers/move-to-premium-support.html) and we would be happy to help you to address this issue.
Alternatively, you may want to use our community-driven technical resource that is completely free: Appeon Community (https://community.appeon.com).  The Appeon Community provides how-to/advice Q&A, technical articles, tutorial videos, and code samples.

Regards,
Mark Lee
Dan Cooperstock 21 September, 2021
*Phenomenon: Either the Help is vague or this is a bug: If you are on the bottom row of a DW and call dw.ScrollNextRow(), it can jump that next row up to immediately be the middle row of the DW (just like a call to ScrollToRow can) rather than just scrolling the DW up by one row, which is at least what the name of the method seems to imply.

See https://community.appeon.com/index.php/qna/q-a/how-to-scroll-a-given-row-to-top-of-dw for why this came up - I was trying to find a way to force a given row number to be the top displayed row in the DW, and there was really no good way to do it with the Scroll...() methods, as far as I could tell, because of this and some other similar unexpected behaviour.
OS:
Windows 10
Platform:
32-bit
Database Type:
Firebird (not relevant)
Database Version: