Dolphin 6 and scroll wheel

Hi all

I have just downloaded and installed Dolphin 6, with no problems at all.
There is clearly a lot to learn, and I have only just started going through
the help, but it all looks very good.

One thing struck me immediately, however, which is that the multi-pane
windows such as class browsers respond to the scroll wheel in the same, to
my mind perverse, way as in D5; i.e. the pane that scrolls is the 'active'
pane, regardless of where the cursor is pointing. I fixed my version of D5
months ago so that the pane that scrolls is the one the cursor is pointing
at, and going back to the old behaviour was driving me mad. The good news is
that installing my scroll wheel change package, with no modification, in D6
changed the scrolling behaviour exactly as I wanted. So my first
'development' exercise was completed successfully.

To my mind this is the way scrolling should work (it is incidentally the way
it works in Squeak, which people may regard as an argument for or against!).
If anyone would like to try my modification, it is kindly hosted for me by
Bill Schwab (http://needle.anest.ufl.edu/anest4/bills/Smalltalk.htm). I have
just sent Bill a slightly cleaned up version, but the functionality is
unchanged. Any comments gratefully received.

Peter Kenny

"Peter Kenny" <[hidden email]> wrote in message
news:[hidden email]...
>I have
> just sent Bill a slightly cleaned up version,

Bill has told me that he will not be able to post the modified version until
Monday. If anyone wants to try the older version before then there should
not be any problems, but it will be as well to use the later version when
possible - it can be identified by an addendum to the package comment dated
Aug 2005.

Peter

"Peter Kenny" <[hidden email]> wrote:
> The good news is
> that installing my scroll wheel change package, with no modification, in
D6
> changed the scrolling behaviour exactly as I wanted.
>
The slightly less good news is that, on further testing, I have found two
cases in which a pane will not scroll unless it is first made active.
Presumably there is something different about the kind of view in these
cases (the decision about whether a pane can scroll is based on the class of
which the view is an instance). I am still trying to work out what is
different and how to modify the methods to take account of the difference.
The two difficult cases I have so far found are:

1. The right hand pane of the code mentor plug-in (the pane named
'infoSite'). The view resource shows this as a ContainerView, but tracing it
through it seems as though it is occupied by an AXValueConvertingControlSite
holding an IE Browser control. I have tried marking the class
AXValueConvertingControlSite as able to accept scroll messages, but this
seems to have no effect. Clicking in the pane to make it active is necessary
to scroll.

2. The listing pane of the Method History Browser. When the browser is first
opened the pane is scrollable, but when the buttons have been used to change
the selected version it is not scrollable until it has been made active. The
pane is a ScintillaView, which is a subclass of MultilineTextEdit which is
scrollable, and scrolling works for the ScintillaView which holds the method
source in the ClassBrowser, so this is a bit if a mystery.

I am still trying to fix both these problems, but meanwhile anyone using my
package will need to take account of these quirks. I still find the change
helpful, but I designed it to meet my preferences so I suppose I am
prejudiced!

Peter Kenny

Peter,

> 2. The listing pane of the Method History Browser. When the browser is first
> opened the pane is scrollable, but when the buttons have been used to change
> the selected version it is not scrollable until it has been made active. The
> pane is a ScintillaView, which is a subclass of MultilineTextEdit which is
> scrollable, and scrolling works for the ScintillaView which holds the method
> source in the ClassBrowser, so this is a bit if a mystery.

I imagine it is just because the focus is left on the button/slider.
Change the first few lines of MethodHistoryBrowser>>updateSelection to read

source
        text: ((history at: selection) at: 3);
        setFocus.

Let me know if it works and I'll add the change to the next version.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

"Ian Bartholomew" <[hidden email]> wrote:

> I imagine it is just because the focus is left on the button/slider.
> Change the first few lines of MethodHistoryBrowser>>updateSelection to
read
>
> source
> text: ((history at: selection) at: 3);
> setFocus.
>
> Let me know if it works and I'll add the change to the next version.
>
Ian

Yes, thanks, that fixes the problem. If it doesn't interfere with anything
else I would be happy to see that change.

I'm still a bit puzzled as to why it is necessary, though - but maybe that
shows that I don't understand Windows. I assume that setting focus is the
same thing as making the pane active, and the whole point of my package is
to grab the #mouseWheeled event from the active pane and send it to the pane
that the cursor is pointing at. Presumably when the mouse wheel is scrolled
while your button/slider has focus, for some reason the usual call to
View>>#onMouseWheeled is not sent. It looks as though I still have some
research to do!

Thanks again

Peter

"Peter Kenny" <[hidden email]> wrote:
>
> Ian
>
> Yes, thanks, that fixes the problem.
>
>
Ian (or anyone else who understands this)

In further testing I have got into a crazy situation. My conclusion that the
problem was fixed was based on a test in the image in which I had applied
Ian's change. When I saved, closed and reopened Dolphin, I found that the
MethodHistoryBrowser seems to be broken - it hangs in a loop whenever I try
to open it. The debugger shows that the problem is that the chunk file
analyser is failing to recognise the end of the change file - somehow,
although it has read to the end, the position is always 2 less than the read
limit.

Trying to restore the situation, I abandoned my image and did a fresh
install, and found that in the new image, with no changes applied, the
MethodHistoryBrowser fails in the same way. But I know that I have used it
successfully earlier today!

Am I going nuts? Please help!

Peter

Peter,

> Am I going nuts? Please help!

I can only speak in relation to this problem :-) but no, you're not
going nuts.  There is a problem with reading the Dolphin change file
when it is under 8192 bytes long and the HistoryBrowser goes into a
tight loop - as you found.

It was quite rare to come across it before as, as a goodie, you had to
file in the HistoryBrowser package and doing that took the change log
past the 8192 byte barrier.  Now that the HistoryBrowser is part of the
image ....

I have got a temporary fix but the easiest way to get round it is to
load a package, any package, into a clean image before opening the
HistoryBrowser.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

"Ian Bartholomew" <[hidden email]> wrote:
>
> I have got a temporary fix but the easiest way to get round it is to
> load a package, any package, into a clean image before opening the
> HistoryBrowser.
>
Ian

Thanks. I have also found that writing any change to the change file after
the session has started will fix the problem. So for instance take any
method, edit in an unimportant space character, delete it, accept. The
'changed' method is written to the change file and the history browser will
now work - but it sees that the change has no effect and ignores it - clever
that!

Back to the earlier question. Your setFocus change does work and fixes my
problem with the scroll wheel package. I still don't see why it was
necessary, but I now have removed one of my problems.

Thanks

Peter

Peter,

> Back to the earlier question. Your setFocus change does work and fixes my
> problem with the scroll wheel package. I still don't see why it was
> necessary,

The only thing I can think of is that the Slider is a sort of scroll
bar.  When it, or it's owning view, has focus it may be absorbing all
the mouse move events and not letting the Scintilla view see them.

But I don't really know - as far as I can see I don't do anything
different to prevent normal Windows operations.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

> Back to the earlier question. Your setFocus change does work and fixes my
> problem with the scroll wheel package. I still don't see why it was
> necessary, but I now have removed one of my problems.

Not sure if this helps - but I have seen this in other applications (non
Dolphin) as well. It also sometimes works differently on different
computers.

My conclusion has always been that not all mouse drivers are equal - the
Logitech ones seem to handle focus scrolling better. Also there is Wndows
add-on that gives focus to whatever is under the mouse cursor (like on X).

It might be interesting to see how your stuff works on a totally different
computer, before you decide you are mad ;-)

Tim

"TimM" <[hidden email]> wrote:

> Also there is Wndows add-on that gives focus to whatever is under the
> mouse cursor (like on X).

That's interesting - if I had that it would presumably make my modification
unnecessary, since the scroll wheel seems to scroll whatever pane has the
focus. Do you have any further details on this add-on, please?
>
> It might be interesting to see how your stuff works on a totally different
> computer, before you decide you are mad ;-)
>
My doubts about my sanity were raised by the strange behaviour of the Method
History Browser, which Ian has now explained. The only remaining issues are
about my not understanding the sequence of events when the mouse wheel is
moved, especially which objects receive the event notification. I just need
to do further research on that, I hope!

Peter

Peter Kenny wrote:
> That's interesting - if I had that it would presumably make my modification
> unnecessary, since the scroll wheel seems to scroll whatever pane has the
> focus. Do you have any further details on this add-on, please?
The tool is called XMouse and can be found here:
http://www.microsoft.com/windows95/downloads/contents/WUToys/W95PwrToysSet/Default.asp

Please note that the automatic focus change is not limited to child
views of a window. It generally follows the X-Windows style of focusing
windows/widgets below the cursor.

CU,

Udo