Listview Behavior w/Mousewheel

Post by **Susan Smith** » Thu Sep 17, 2009 9:15 pm

I hope someone that has a lot of experience in listviews reads this. I'm frustrated after messing with this for hours and I hope that it's just something I'm doing wrong.

Tell me if you get this behavior from a good-sized listview (mine has about 2500 records in it):

The listview is too long to scroll through it with PgUp and PgDn or arrow keys or the mouse wheel and I'm looking for a particular record. So I drag the thumb on the vertical scroll bar down to get to the approximate place where I need to be. At that point, if I move the mousewheel (or use any other method of navigation besides the scroll bar dragging) to continue to move more slowly through those records, the listview jumps to another place in the list entirely! The does NOT happen if move the scroll bar, and select/highlight a row in the list and THEN continue to move it further by the mousewheel or keyboard keys. But I'm sure that if the user hasn't found the record they want yet, that they aren't going to artificially highlight a row just so they can change their navigation/scroll method from dragging the scrollbar to using the mousewheel. Am I the only one that this is happening to?

Note that I have similar probably with horizontal scroll bars on listviews and grids. If you drag the scroll bar all the way to the right to see the hidden right end of the listview, and then you move your mousewheel up or down or use the keyboard keys, the listview/grid snaps back to the left side of the listview or grid.

I know that my client is going to send me right back to fix this as soon as they see it next week. Any ideas?

-- Susan

Post by **Susan Smith** » Thu Sep 17, 2009 9:31 pm

I should add that I am using BR 4.18

-- Susan

Larry TIetz · Post by **Larry TIetz** » Fri Sep 18, 2009 3:25 am

Glad u asked. I too have been frustrated by this "feature".

I need to put posting these kinds of things into my thought process, rather than "living" with these quirks or trying endless workarounds.

Waiting for a good answer....

John · Post by **John** » Fri Sep 18, 2009 7:03 am

I believe if ADS we're to enhance the grid control to scroll with the vertical scroll bar when the mouse was hovering over it instead of allowing it to press the up/down arrow keys we'd have behavior consistent with excel and our expectations as users.

-john

John · Post by **John** » Fri Sep 18, 2009 7:11 am

when hovering over the *grid* (i should have said)

gtisdale · Post by **gtisdale** » Fri Sep 18, 2009 7:11 am

THis is a problem that exists in many programs, not just BR. My tax software, which is the top of the line has similar behavior, the cursor movement controlled by the arrow keys and the cursor movement controlled by the scroll wheel are disconnected, swithching from one to the other casues the selection to jump back to where the cursor was the last time the other was used. Very frustrating for a user I agree.

As to finding a particular record by scrolling, sliding, arrowing, paging etc. I early on decided that this was generally not an efficient way to find something. So I created a function (I know this surprises you). Because the data in the list/grid is contained in a number of arrays, which can either be character or numeric this creates a small problem, but it is surmountable. The other thing that I decided was that I wanted to be able to search on any part of the contents of each record, not just the start and I wanted to search case insensitive.

For example, I live in the town of Concord and lots of my client names start with "Concord ". I want to be able to specify a semi-unique string that finds what I want out of a couple of thousand names. So, if I type "rd ar" in my search criterea box I immediately find Concord Art Association, if this isn't the one I want I press the F3 key and the bar moves to the next matching record. Best of all, the selection works on multiple arrays in the display simultaneously and I can programmatically include or exclude any of the arrays.

The function works by searching each selected array in upper-case and adding the element number to a "SELECTED" array. Once all of the target arrays have been searched CURFLD(X,Y) is set to the value of SELECTED starting at element 1. F3 then moves CURFLD(X,Y) down an element and when then end is reached recirculates back to 1 again.

No longer do I battle with sliders, scroll wheel jumping, or limitatins of alphabetical order.

The functions are in FNSNAP (surprise, surprise) named FNLISTSRCH and FNLISTSRCHN. These create the SELECTED ARRAY.

The search box is opened with FNSRCHCRIT$ also in FNSNAP

Hope this is helpful.

Post by **Susan Smith** » Fri Sep 18, 2009 7:48 am

Hi George,

This may be a problem in other software out there somewhere, but *I* have not seen it before. I use listviews and grids in commercial and open source software all day long. I can hardly appease clients by using that response. It will be of small comfort that someone else's software might have the same defect.

I don't have the opportunity of using FNSNAP functions in this particular situation so I have to figure out another way. But I appreciate knowing about your workaround. I think that this really needs some immediate attention. Listviews and Grids are essential in GUI.

Just curious...I know that Steve and Luis deal with large amounts of data with grids and listviews. Do you see this behavior exhibited? And what, if anything, do you do about it?

-- Susan

bluesfannoz · Post by **bluesfannoz** » Fri Sep 18, 2009 8:02 am

Susan
My experience has been with Multiple programs including Excel that it exhibits the same behavior. Keyboard and Mouse Selection are independent of each other. When scrolling using the bar, you must always select something within your visible window before you switch to using the keyboard because your focus has never left the original location. A single click of something in the visible window is all it takes.

My Users have yet to complain about this anymore than I do myself anytime I forget to click something in the visible Window. GUI applications have always been driven by focus. I don't want the scroll bar moving focus. Because that is not typical Windows behavior.

Steve

Post by **Susan Smith** » Fri Sep 18, 2009 8:10 am

Thanks Steve. That at least gives me a concrete explanation that I can offer them which doesn't make it look like I'm complete inept. It won't be the first time that I blame something on Windows

I think that to make it easier on the users mostly likely to be confused, I will try to narrow down these long listviews with pre-searches in order to minimize the need to traverse long lists.

-- Susan

dmeenen · Post by **dmeenen** » Fri Sep 18, 2009 8:18 am

Susan,
Fileio has a Search by Key in a listview.
It is helpful when there are thousands of records in the file displayed in the listview.

John · Post by **John** » Fri Sep 18, 2009 8:23 am

we add our search functions to pretty much any grid of any medium or larger size.

Post by **Susan Smith** » Fri Sep 18, 2009 9:10 am

Doug and John,

I do intend to put searches in the listviews. I'm sure that will help. The snag that I run into is that one of these listviews is most often used to find things when they don't KNOW exactly what the search criteria is. For instance, they THINK they received a donation back in March from someone whose name started with an "A" (or perhaps that was the business name...). So they sort the listview by name and scroll down, looking for it. I they don't see it, they sort the list by date and hunt through the March receipts.

In these cases, it's harder to do a search. We'll just have to manage I guess. But I would like to say one thing. Not all programs exhibit this grid behavior that is confounding me. One example off the top of my head is Mozilla Thunderbird. It handles grids like a dream! I have hundreds of thousands of messages (don't ask...) saved in my Mozilla Thunderbird database and I wouldn't change a thing. This should be a model for all other software as far as I'm concerned.

-- Susan

Post by **gordon** » Mon Sep 21, 2009 3:24 pm

Wouldn't it be useful to make up a listview that included the key fields that a user might want to search on, and then attach a search field?

Then the user could find what they want by clicking on the column they want to search and then begin typing into the search field the corresponding key info to narrow the search. The fact that the search field applies to the last column sorted makes it flexible in this regard.