Baby Scroller 101 Help Please

[Tom]

My user defined vertical scroll bar does not respond properly. :(

public VScrollBar vs;
....
vs = new VScrollBar();
vs.Parent = this;
vs.Dock = DockStyle.Right;

I intercept the scrollbar events using the Visual Studio's very nice
automated event handler: >>

vs.Scroll += new ScrollEventHandler(vs_Scroll);

Then I programmatically calculate and set the desired new position for
the thumb in the LargeDecrement event: >>

public void vs_Scroll(object sender, ScrollEventArgs e)
{
if (e.Type == ScrollEventType.LargeDecrement)
{
vs.Value = iThumbLocation(); //The calculated result.
return;
}
}

The observed behavior is the thumb moves by the "LargeChange" amount
from the _original_ position. Upon losing focus, it then snaps to the
calculated value.

What is the smart solution here?

Do you somehow trap out the automated scrollbar behavior?

Or, should I be programmatically calculating and setting a new
"LargeChange" value to keep the "while still in focus scrollbar"
visually in sync with the calculated new position?

Unfortunately the false value also triggers another scroll event! What
a mess. It really had(has) me dumbfounded and the amount of time I've
spent writing out values to understand what was causing the visually
observed problem is good for a laugh. Please enlighten me! This is one
more learning adventure I'll very much enjoy having completed.

Thanks!!

-- Tom

[Tom]

>[...]

>I hope the above sheds some light on my predicament and the peculiar
scrollbar behavior I am trying to work around.

I apologize if I'm missing something, but unfortunately, no. It doesn't
shed light on the question I asked. I still don't understand why you're
setting the Value property in your handler.

Pete

Pete -- Have you ever seen the movie "Kill Bill" (Two Parts: 1 & 2)?
One of my favorite lines is >"I must warn you ... I am very
susceptible to flattery." Awesome movie ... but now to my coding
challenge.

I set the vertical scrollbar(vs) "Maximum" to the file size in bytes.
^^ See! I do learn. The above is from some previously received help in
here!! :)) Before, I was even more scrollbar dumbfounded!

vs.Maximum = (int)myFile.Length;

When I drag and drop the thumb ... no problems at all. The vs.Value
works precisely and allows the buffer to be filled at that placement.

However, when I click for a LargeIncrement change ... the file is so
large that the thumb just sits there as the pages fly by. I am use to
being able to traverse the scrollbar rapidly by holding down on the
area above and below the thumb (instead of dragging the thumb). To
gain this type of behavior requires larger step sizes. And is
accompanied with "jumps" in the very large files. Non-contiguous
scrolling is not ideal ... but my goal is a minimal footprint viewer
that is fast. Minimal footprint defined as reasonably conservative
memory usage. On small files I programmatically set the LargeIncrement
to the conventional one page size. On the large files accurate control
requires using the PageDown & PageUp buttons for paging and the
Up/Down Arrows for moving the caret one line at a time. I intend to
implement CTRL-Home & CTRL-End too.

High performance for most folks is having the entire file in memory
and smoothly scrolling from begin to end with no flickering. In my
case ... high performance is loading speed and minimal usage of
memory. Tough compromises thus were required. Typical usage will be to
observe either the beginning or end of a log or data file while other
memory intensive and higher priority programs are running. An example
being a stock tick data file stored in bulky ASCII format. A data
vendor I use follows that format and there are some benefits in it
being easily read.

I have found a "hack" solution that produces less than perfect
results. >>

int tempValue = vs.Value;
.... perform buffer loading and new vs.Value calculation
vs.LargeChange = Math.Abs(tempValue - vs.Value);

The above is definitely a "hack". :((

The old "Value" is retained by the scrollbar while it has focus and it
reacts to the freshly calculated "LargeChange".

The thumb expands and contracts along its rapid traverse. The thumb
size changing is disconcerting ... but at least the travel time is
quick.

I've tried using 'Focus', 'Refresh', 'Invalidate' ... all to no avail
as yet.

I was hoping for some sort of C# solution that perhaps used the base
class somehow? I am clueless and speculating further about things
beyond my skill level are senseless. One thing for certain is the
focus that scrollbar retains even after the mouse is hovering
elsewhere. I have to click in the textbox to relinquish the scrollbar
focus.

Hopefully the above fills in some gaps on my challenge. If only there
was some way to disable the automated scrollbar behavior and be fully
in control!

Interestingly I saw a recent conversation about a 3 pane scrollbar
challenge another is up against. ;) (And I thought scrollbars issues
only concerned newbs!) I also noticed some commercial scrollbars at
outrageous prices for the fancy eyecandy stuff.

Thanks for listening and any suggestions thrown my way.

-- Tom

[Peter Duniho]

On Fri, 18 Jan 2008 01:34:13 -0800, Tom <Th********@earthlink.netwrote:

[...]
However, when I click for a LargeIncrement change ... the file is so
large that the thumb just sits there as the pages fly by. I am use to
being able to traverse the scrollbar rapidly by holding down on the
area above and below the thumb (instead of dragging the thumb). To
gain this type of behavior requires larger step sizes. And is
accompanied with "jumps" in the very large files. Non-contiguous
scrolling is not ideal ... but my goal is a minimal footprint viewer
that is fast. Minimal footprint defined as reasonably conservative
memory usage. On small files I programmatically set the LargeIncrement
to the conventional one page size. On the large files accurate control
requires using the PageDown & PageUp buttons for paging and the
Up/Down Arrows for moving the caret one line at a time. I intend to
implement CTRL-Home & CTRL-End too.

I agree that non-contiguous scrolling is not ideal, but if you're okay
with that design even so, let's consider that the design goal here.

In that case, large files are still handled the same as small files,
except that you set LargeChange differently. Basically, you should have
some code like this when you choose a new file for the viewer:

// calculate what the LargeChange value would be based on file size
int scrollLargeChange = cbFile / 100; // for example
int scrollViewChange = cbOnePage;

LargeChange = Math.Max(cbFile, cbOnePage);

The first value is how much you'd want to scroll for large files. In the
example, it means that 100 large-change scrolling actions will be required
to page through the whole file. Obviously this calculation is dependent
on the actual length of the file.

The second value is the nominal amount you'd page for smaller files,
corresponding to how much data you can fit on the screen at once. It's
completely independent of the actual length of the file, and relates only
to the display of the data.

Then, you want the large of the two values for your LargeChange property..
You always want to page at least one screen's worth of data, but if that's
less than 100th of the file, you want to page an even larger amount, equal
to 100th of the file.

At no point should you be setting the Value property of the scrollbar
directly, at least not with respect to this part of the code (obviously to
support your custom handling of the PageUp and PageDown buttons and any
other key-specific handling, you'll need to do so).

Pete

[Tom]

>At no point should you be setting the Value property of the scrollbar
directly, at least not with respect to this part of the code (obviously to
support your custom handling of the PageUp and PageDown buttons and any
other key-specific handling, you'll need to do so).

Pete

Thanks Pete !!

I have already implemented a linear calculation (and considered
non-linear) with a lower limit very similar to your suggestion. The
trap I fell into was "the setting" of the scrollbar's Value!!

Implementing the PageUp, PageDown, and ThumbPosition events first
(where I needed to be "directly" involved with setting or using the
"Value") made me feel I should _always_ position the thumb for every
event. That is just the wrong approach for Large and Small Increments.
The light is on now!!

Golden Scroll Bar Rule #1:

When programmatically responding to Large or Small Increment events
that differ from the traditional One Page or One Line movement ...
simply adjust the viewing area however you need and let the
scrollbar's built in tracking methods work as they are designed.

Amazing how hours of writing trap code drew me in so tight my nose was
on the tree's bark and I could not see the forest. I just could not
force myself to think outside making adjustments to those two critical
parameters! Now if only I could quit saying "dumb dumb dumb" to
myself!!

Geez, I had begun to be obsessed with needing an "e.Handled" method
similar to keystroke trapping. I was also starting down the path of
wanting to intercept the Window Message traffic. A newb gets exposed
to more new things when traveling the endless wrong paths once sight
of the logical approach is lost.

Pete -- You recognized my problem and kindly got me pointed right.
Thank you again !!!

-- Tom (alias: tweedle dee tweedle dumb) LOL