Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Scroll bar mouse click
Message
General information
Forum:
Visual FoxPro
Category:
Other
Environment versions
Visual FoxPro:
VFP 5
OS:
Windows 2000 SP2
Network:
Windows XP
Database:
Visual FoxPro
Miscellaneous
Thread ID:
01056319
Message ID:
01056533
Views:
18
>I have something that needs to be resolved, or my company will have to spend tens of thousands of dollars.
>
>What I am trying to address is the function of the scroll bar slider/elevator, on a grid control, within XP Professional (Service Pack 2 or higher), operating in a terminal server environment.
>
>If I click in the white space of the scroll bar, in a location that allows the elevator to scroll about 1 page at time, and the click is in such a place that the elevator can go all the way to the bottom...
>The scroll bar becomes non-functional for a few seconds...
>As if the keyboard buffer still has info it's sending.
>
>This seems to be the case if the number of lines/records traversed is not a multiple of the number of lines/records traversed by a single click of the mouse. What I mean is, if the number of lines/records traversed by the mouse, when you click in the white area, is 10 lines/records, and the number of lines/records that are in the grid is not a multiple of 10, then the behavior is seen... especially if the mouse left key is kept depressed for a short time after getting to the end.
>
>What settings are there that can influence the scroll bar?
>
>I need this answer ASAP!
>
>If need be please contact me directly at
>
>Rick
>@
>omniagroup.com
>
>Thank you!


The only thing this brings to mind is the inherent slowness possible if you are using a recordsource looking at a filtered table directly that is rather large. As you navigate the table (for example, do a page down in a browse window looking at filtered data) the engine has to check each record to see if it matches the filter criteria or not until it has enough to fill up the window/browse screen/grid. Since there are only 10 rows, say, in the browse window 10 matching records get found (normally) rather quickly and the engine stops. Once you get to the last matching record (or a huge gap in matching records) there still might be many thousands of records to go and the engine must navigate through each and every one of them to make sure they don't match the filter criteria. The system appears to lock up while this searching is going on. Optimizing the filter can help. But a better solution is not to do grids on filtered data directly but to use an SQL select as a record source (i.e., get rid of the filter right at the beginning so the navigation in the grid doesn't have to think about it).

Not sure if this is the cause in your case but it's what comes to mind from your description.

Good Luck!
Steven D. Supinski
The American Contractor
Santa Cruz, CA 95062
Phone: (800) 333-8435 ext 4017
Email: ssupinski@theamericancontractor.com
Previous
Reply
Map
View

Click here to load this message in the networking platform