I'm struggling with the "wrapping" feature in listviews when you scroll with the mouse wheel up or down past the beginning or end. My users positively HATE this behavior and I can't get it to turn off properly with the "L" attribute. My understanding is that when you use the "L" attribute in your listview form specs, that the highlight bar (and scroll bar thumb) should STOP when they get to the top or bottom (like any other Windows program). This is not the behavior I'm seeing.
When I hit the end of the listview, the cursor jumps back up a certain percentage of the way in the list and continues to scroll (loop) through that portion as you continue to scroll. This can be a BIG jump if you happen to have a long listview. It seems to be a percentage, but I haven't nailed that down.
Scrolling UP past the beginning doesn't appear to be affected at all by the "L" attribute as far as I can tell. I've tested this with different versions of BR from 4.17 through the most current 4.2 posted this week.
I really need to figure this out as my users want me to abandon listviews and go back to the old FNKEY Select "scrolls" if I can't turn this off. And I just created several new listviews that I really don't want to abandon.
Any ideas? Do any of you use the "L" attribute on your listviews? And if so, when you scroll (usually with the mouse wheel) past the beginning and the end, does it stop there? (maybe the problem is only mine) Are there any config values that affect listview scrolling? Maybe I don't have that set. (couldn't see any in the wiki)
-- Susan
Scrolling/wrapping in Listviews and the "L" attrib
Moderators: Susan Smith, admin, Gabriel
-
- Posts: 717
- Joined: Sun Aug 10, 2008 4:24 am
- Location: Southern California
-
- Posts: 717
- Joined: Sun Aug 10, 2008 4:24 am
- Location: Southern California
(note sure why John's reply didn't come through the forum, but oh well...I'll copy it here)
John,
I tried that, but those fkeys don't appear to work in listviews. Perhaps they only work in grids. In my case, these are definitely listviews. Thanks anyway.
-- Susan
John Bowman wrote:
Susan, - from a grid with the L attribute, you should get an FKey of 105 or 106 when you attempt to scroll past the bottom or top of the grid. when this happens I believe you can just go back to the input statement.
From a GRID with L attributes
FKey value Cause Additional
105 Attempt to Scroll past top
106 Attempt to Scroll past bottom
-john
John,
I tried that, but those fkeys don't appear to work in listviews. Perhaps they only work in grids. In my case, these are definitely listviews. Thanks anyway.
-- Susan
John Bowman wrote:
Susan, - from a grid with the L attribute, you should get an FKey of 105 or 106 when you attempt to scroll past the bottom or top of the grid. when this happens I believe you can just go back to the input statement.
From a GRID with L attributes
FKey value Cause Additional
105 Attempt to Scroll past top
106 Attempt to Scroll past bottom
-john
-
- Posts: 717
- Joined: Sun Aug 10, 2008 4:24 am
- Location: Southern California
-
- Posts: 717
- Joined: Sun Aug 10, 2008 4:24 am
- Location: Southern California
John,
You were right about the fkey 105 and 106 in listviews. My problem was that these listviews were created with ScreenIO and it wasn't sending the program back to the rinput fields when one of these fkeys fired. Thanks to you and Gordon. I have it working now. Halleluia!
One question though: Are function keys 105 and 106 only used in listviews and grids or is there another situation where they may be set? Secondly, what is their purpose and why would you check for them normally? Why would I NOT want to ignore them?
-- Susan
You were right about the fkey 105 and 106 in listviews. My problem was that these listviews were created with ScreenIO and it wasn't sending the program back to the rinput fields when one of these fkeys fired. Thanks to you and Gordon. I have it working now. Halleluia!
One question though: Are function keys 105 and 106 only used in listviews and grids or is there another situation where they may be set? Secondly, what is their purpose and why would you check for them normally? Why would I NOT want to ignore them?
-- Susan
FKEY 105 is "upfld" and 106 is "dnfld" in TT. These are the fkeys that are generated if a field is exited with an up arrow or a down arrow as opposed to a left arrow or a right arrow (assuming an event is triggered like with an X attribute or an L attribute).
These are not often important and therefore not often trapped, but in a list or grid can be very important.
These are not often important and therefore not often trapped, but in a list or grid can be very important.
-
- Posts: 717
- Joined: Sun Aug 10, 2008 4:24 am
- Location: Southern California
Susan,
maybe you have a small listvfiew with, say, three options. And you have a text box on the screen too. You may want to make it so that the down arrow, scrolling down past the listview data, takes you to the textbox.
Perhaps you want scrolling up to do nothing and scrolling down to go to the text box. (because the listview is above the textbox on the screen).
This is just one example of a place where you might actually trap for and use the fkey 105 and 106.
Gabriel
maybe you have a small listvfiew with, say, three options. And you have a text box on the screen too. You may want to make it so that the down arrow, scrolling down past the listview data, takes you to the textbox.
Perhaps you want scrolling up to do nothing and scrolling down to go to the text box. (because the listview is above the textbox on the screen).
This is just one example of a place where you might actually trap for and use the fkey 105 and 106.
Gabriel
Susan Smith wrote:Hey George,
I'm not using any grids yet. But can you tell me why someone would want to trap FKEY 105 or 106 in a LISTVIEW (other than to send it back to the RINPUT statement?) I'm sure there's a reason (at least for grids), but it's purpose is evading me in the listviews.
-- Susan
-
- Posts: 717
- Joined: Sun Aug 10, 2008 4:24 am
- Location: Southern California