Button action is unreliable in List View
Operating system version
Description of the issue
Buttons on a list view cannot be relied upon to act when clicked. Based on my experimentation, the rules appear to be these. If the button belongs to the current record, or if the record is fully scrolled into view, then the button will do what it is programmed to do. Otherwise, the effect of clicking the button is that the owning record becomes the current record and it is scrolled into view.
I imagine that this seemed like a good design decision at the time it was made, but it isn't. Consistent behavior of user interface elements should take priority over the other concerns that motivated this design decision.
Recommended solution: let buttons do their thing whenever they're clicked.
A workable alternate solution, if you're really set on preserving something like this, has two parts:
1. If a button isn't going to act, then it should not highlight on mouse over. The way it currently highlights is false advertising.
2. Provide an opt-out for developers like me who have good reasons to need a button to do its thing even when the whole record isn't in view.
(In my case the buttons are for insertions and order changes at the boundary between two records, so the user is focused on the boundary and is not interested in seeing the upper record in its entirety. The button's scrolling effect is quite disorienting and the user has a hard time telling whether the insertion or order changed happened. Very bad user experience.)
Steps to reproduce the problem
Make a simple table. Edit its layout to have a button on it that beeps, and make each form fairly tall, e.g. 1/4 of screen height. Go to List View. Experiment with clicking the beep buttons. You'll find that when a non-current record is scrolled off the top, its beep button fails to beep.
All beep buttons should beep.
When a non-current record is partially scrolled off the top, its beep button fails to beep, and instead selects the record and scrolls to it.
A big problem with this bug is that there is, as far as I know, no way to compensate for the behavior in scripting. FM heads off the button action before I can do anything about it.