I have a grid that has 50+ columns but only about 10 are visible per default. So when the user wants to see more, he opens the column chooser which will come up with a scroll bar because of the number of columns. If some entries in the column chooser are not visible (would become visible if I scroll further down) and I click on the last visible item, this item gets the focus, is scrolled up by 1 -> is now the second last visible entry, and the new last entry is checked. This is really annoying. Is there any workaround? I'm using version 11.1.20111.2111
Thanks
Bettina
Hi Bettina,
No, there's nothing we can do about this. The ColumnChooser is actually a modified WinGrid. So when you click on a header, you are actually clicking on a WinGrid row. What happens is that when you MouseDown on the row, it becomes the ActiveRow and scrolls into view. Then by the time you release the mouse, the row you originally clicked is no longer under the mouse and a new row has moved into that spot.
I suppose one thing you could do is make the ColumnChooser taller so the user doesn't have to scroll as much and that should alleviate some of the issue.
Hi Mike,
sorry I think you misunderstood my description. Lets assume I have "item A", "item B", ..."item F" in the column chooser. "Item B", "item C", "item D" are in the visible section of the column chooser. So if I wanted to see A or E or F, I would have to use the scroll bar. So in this state "item D" is the last visible item. I click on "item D". Now "item D" gets the focus (highlighted) this is correct. The visible area is shifted, so now "item C", "item D" and "item E" are visible. I'm ok with that. BUT "item E" gets checked instead of "item D" where I clicked on. This is the problem/error.
Regards
I agree with you. This is an unfortunate result of the grid's architecture. We've tried quite a number of potential solutions over the years, but so far, we haven't been able to come up with one that doesn't break existing functionality.
Thanks for the clarification. Now I understand what happens. Still, if I click on "Item D" (that not completely but mostly visible) "item E" should not get the checkmark. This sounds like an execution order bug. I guess you can't change that, but wouldn't it be possible to remember if it had to be scrolled when it became the active row and then act accordingly in the MouseUp event? I will try to implement that fix myself, but I think it should be fixed (possibly like this) in column chooser itself, because every customer who sees that the item below the clicked one gets checked will think it is a bug (which it really is from the user point).
Especially if you ran into the problem, you will intuitively click on "item E" to deselect it. This will move E up, and select F instead of delecting E... Until you realize, you have to use the scrollbar to get out of this (or you reached the end of the items).
Thanks for your explanations
Regards,
I understood you perfectly the first time.
In your example, item D is not completely visible - it is only partially visible. If it were completely visible, then no scrolling would occur. Since item D is partially visible, clicking on it makes it the active row and it scrolls into view. This happens on the MouseDown. By the time MouseUp fires, the scrolling operation has completed and item E is under the mouse, so that's the item that gets checked.