From: Bee on
I use several scrollbars.
THese repeat without having the mouse down.
Click on the up or down button, release, ove the mouse away, the scrollbar
sub runs, move the mouse back over the button without clicking and the button
fires again, but only one again.
So I added a static bWorking but it does no good since the sub has completed.
So I added timers to have the scrollbar click trigger a timer with a 200
msec interval.
This did not work.
I seems related to time consuming code running adfter the scrollbar click.
But that code does nothing with a scrollbar.
Also, if I click in the area between the thumb and the button at the end,
other scrollbars sometimes turn black. These are Indexed scrollbars.

And no, I do not want to make a user control. I have several user controls
and when I get a crash in the IDE I have to change all the pictureboxes that
show up back to my user control.

An no, I do not know how to subclass this control to watch messages.

From: Nobody on
"Bee" <Bee(a)discussions.microsoft.com> wrote in message
news:F65DB1FC-5114-4FD1-B492-5B27762B2118(a)microsoft.com...
>I use several scrollbars.
> THese repeat without having the mouse down.
> Click on the up or down button, release, ove the mouse away, the scrollbar
> sub runs, move the mouse back over the button without clicking and the
> button
> fires again, but only one again.
> So I added a static bWorking but it does no good since the sub has
> completed.
> So I added timers to have the scrollbar click trigger a timer with a 200
> msec interval.
> This did not work.
> I seems related to time consuming code running adfter the scrollbar click.
> But that code does nothing with a scrollbar.
> Also, if I click in the area between the thumb and the button at the end,
> other scrollbars sometimes turn black. These are Indexed scrollbars.

Do you do any lengthy operation when the scroll position changes? If so, you
need to add DoEvents and check for a bCancel variable that is set by
scrollbar events when the position changes, or make the long running routine
check for the scrollbar Value property. In either case, you have to use
DoEvents to make it the scrollbar responsive.

> And no, I do not want to make a user control. I have several user
> controls
> and when I get a crash in the IDE I have to change all the pictureboxes
> that
> show up back to my user control.

I use WinMerge when this happens and compare with the last backup. It
highlights the GUI differences which are in the file header, then copy the
GUI changes back without affecting the code. This way I don't have to
examine or change any property.


From: Karl E. Peterson on
Bee wrote:
> An no, I do not know how to subclass this control to watch messages.

Do you want to?

--
..NET: It's About Trust!
http://vfred.mvps.org


From: Bee on
Since nothing that I have tried or has been suggested works, then maybe yes
if it means that I can somehow trap and kill any errant messages.
Tried DoEvents, Timers, ReEntry stopping.

I remember, years ago, that I saw an example app, maybe from a textbook,
that seemed to show all messages being processed and gave an understandable
description. It allowed seletion of controls for monitoring. Unfortunately,
I have been unable to find that example in my dozens of VB books.

So, is there such a verbose app with source code around that I might
understand?

"Karl E. Peterson" wrote:

> Bee wrote:
> > An no, I do not know how to subclass this control to watch messages.
>
> Do you want to?
>
> --
> ..NET: It's About Trust!
> http://vfred.mvps.org
>
>
> .
>
From: Mike Williams on
"Bee" <Bee(a)discussions.microsoft.com> wrote in message
news:2FA3E99E-7742-4FEF-A86A-4874A5827138(a)microsoft.com...

> Since nothing that I have tried or has been suggested works, then
> maybe yes [to subclassing] if it means that I can somehow trap and
> kill any errant messages.Tried DoEvents, Timers, etc

DoEvents is not the solution to your problem, it is the cause of it (in
conjunction with buggy ScrollBars of course!). Remove all DoEvents from your
"takes some time to execute" code that is being called by your ScrollBar,
and from any routines that the code might itself be calling, and your
problem will go away. If you definitely want to keep the DoEvents in your
code (which I would advise against) then you can "kludge your way out of"
your specific problem of "repeat without actually clicking" by using a call
to ReleaseCapture, but that can (in fact almost certainly will) cause other
strange graphic anomolies to happen to the scroll bars that will probably
bother you even more. Better I think to remove the DoEvents. It will save
you a lot of subclassing messing about with buggy Scrollbars. Otherwise,
perhaps writing your own UserControl might be the way out.

Mike