Mouse scroll wheel and active pane

If I open a Class Browser window, select a method and move the cursor into
the method source pane, I cannot scroll the source code with the mouse wheel
unless I first click to make the source pane the active pane. Similarly in
my main app, which has a layout based on the CHB, I have to click to make a
text pane active before I can scroll it. However, when reading this
newsgroup in Outlook Express, I can select a post in the list pane, move the
cursor into the text pane and immediately scroll it, even though the list
pane is still nominally the active one (as shown by the blue highlight on
the selected post). Reading my e-mails in Outlook has the same effect; the
pane that scrolls is always the one the cursor is in, regardless of any
active status. Is there any way I can easily modify my app to behave the way
that Outlook (+Express) do? Would it not be more intuitive to have this the
default response to the scroll wheel?

Thanks for any suggestions

Peter Kenny

Peter,

> that Outlook (+Express) do? Would it not be more intuitive to have
> this the default response to the scroll wheel?
>
> Thanks for any suggestions

This point was raised back in October 2001 and Blair's response then was as
follows (he may, of course, have a different opinion now)...

~-~-~-~-~-
Dolphin does not intervene in the handling of the mouse wheel at all at
present, so the behaviour you are seeing is standard for windows and its
common controls. I'm not sure which particular "other" applications you are
referring to, but they are the exception rather than the rule as far as I
can tell - for example the Windows explorer works in the same way as
Dolphin, as least on Windows 2000. I agree that the behaviour you suggest
makes more sense, but Windows sends the mouse wheel messages to the window
with focus so it is somewhat awkward to correct in a generic way at the
application level.
~-~-~-~-~-

FWIW, MS Media Player behaves in the same way as Dolphin, as does some other
(non MS) apps I looked at.

The place I always notice it is when a ComboBox has focus and I want to
scroll its owners (usually web) page down.  I automatically use the mouse
wheel for the scroll and, of course, end up changing the combo box position.

--
Ian

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

"Ian Bartholomew" <[hidden email]> wrote in message
news:[hidden email]...
> This point was raised back in October 2001 and Blair's response then was
as
> follows (he may, of course, have a different opinion now)...
Ian

I guessed that I might be reopening an old issue - it's just that I have
only recently started using Dolphin seriously, so it's all new to me.

Following up the quote from Blair, I have looked at a few applications. He
is quite right that Windows explorer only scrolls the active window. I have
not been able to produce a multi-pane setup using Excel or MS Word, so I
can't say about them. As I said before, both Outlook and Outlook Express
scroll the pane containing the cursor. I looked at Internet Explorer when
showing a multi-frame page (e.g. the Google display of this newsgroup), and
there also you can choose which frame to scroll just by moving the cursor
into it. Looking at non-MS apps, I have just loaded Visual Prolog to play
with it, and that behaves like Dolphin. On the other hand, I have looked at
the Muse tool from S#, and there the pane containing the cursor is scrolled
regardless.

So the picture is mixed, but quite a few applications do work differently
from Dolphin. Maybe Microsoft keep the method hidden from the rest of the
world (except that S# has clearly cracked it). I don't fancy trying to take
S# apart to see how it is done, so my appeal remains - can anyone tell me a
way of putting it into my Dolphin app?

Thanks

Peter

"Peter Kenny" <[hidden email]> wrote in message
news:[hidden email]...

> I don't fancy trying to take S# apart to see how it is done,

However, since nobody came up with an alternative approach I decided to give
it a go, and the S# code turned out to be quite easy to follow. I have now
got it working in Dolphin, and in my view it makes all the Dolphin tools
much easier to use. Intercepting the scroll wheel messages and testing
whether the cursor is in the active pane is quite straightforward; the only
PITA was finding a way to identify the pane containing the cursor. I have
cracked this with one minor qualification (see the package comment). I now
intend to make this part of my standard image.

I don't have a working web site, so I have attached the text of the package
to this post - it's only half a dozen loose methods, about 5KB in total, so
I hope this is OK. Any comments or improvements gratefully received. If OA
agree that this is how Dolphin should be, they are welcome to use it.

Peter Kenny

Text of package
-~-~-~-~-~-~-~-~-~-~-~
| package |
package := Package name: 'ScrollWheelChange'.
package paxVersion: 0;
 basicComment: 'ScrollWheelChange
-----------------------

This package contains loose methods for View and some of its subclasses
which modify the way panes respond to the scroll wheel. The standard Dolphin
response is to scroll the active pane regardless of the location of the
cursor. With this change, if the cursor is not in the active pane, the
scroll wheel message is rerouted to the pane containing the cursor if that
pane is one that can ''sensibly'' accept such a message - otherwise it still
goes to the active pane.

The inspiration for this package is the Muse tool of S#, and the definition
of panes that can accept a rerouted scroll wheel message is based on that in
Muse. In this version, instances of ListBox, ListView, TreeView,
MultilineTextEdit, MoenTreeView and their subclasses can accept a rerouted
scroll message; here MoenTreeView is added to the Muse list so that all
panes of the Class Browser window may be scrolled. Other classes may easily
be added if desired; all that is necessary is to implement the instance
method #canAcceptReroutedWheel in the selected class to answer a value of
true.

The methods have been tested on a variety of Dolphin system windows, and
have generally proved reliable. The one exception found so far is that, if
the class diagram pane of the Class Browser window is active, the scroll
messages are sometimes not rerouted. This seems quite unpredictable, and as
yet I have no explanation, though it seems to have something to do with the
order in which panes are scrolled. Messages are always rerouted /to/ the
class diagram if another pane is active.

It should be noted that the changes cannot be applied selectively to
particular windows; if they are implemented they affect all windows in the
image. Selective application would require subclassing View and the selected
classes listed above, and implementing #canAcceptReroutedWheel differently
in the original classes and the subclasses.

Any comments or improvements gratefully received.

Peter Kenny
[hidden email]

10 November 2004
'.


package methodNames
 add: #ListBox -> #canAcceptReroutedWheel;
 add: #ListView -> #canAcceptReroutedWheel;
 add: #MoenTreeView -> #canAcceptReroutedWheel;
 add: #MultilineTextEdit -> #canAcceptReroutedWheel;
 add: #TreeView -> #canAcceptReroutedWheel;
 add: #View -> #canAcceptReroutedWheel;
 add: #View -> #onMouseWheeled:;
 yourself.

package binaryGlobalNames: (Set new
 yourself).

package globalAliases: (Set new
 yourself).

package allResourceNames: (Set new
 yourself).

package setPrerequisites: (IdentitySet new
 add: 'Object Arts\Dolphin\MVP\Views\Common Controls\Dolphin Common
Controls';
 add: 'Object Arts\Dolphin\MVP\Views\MoenTree\Dolphin MoenTree View';
 add: 'Object Arts\Dolphin\MVP\Base\Dolphin MVP Base';
 yourself).

package!

"Class Definitions"!


"Global Aliases"!


"Loose Methods"!

!ListBox methodsFor!

canAcceptReroutedWheel

 "Answer whether the view may be scrolled by a rerouted wheel message - true
in this case"
 ^true
! !
!ListBox categoriesFor: #canAcceptReroutedWheel!public! !

!ListView methodsFor!

canAcceptReroutedWheel

 "Answer whether the view may be scrolled by a rerouted wheel message - true
in this case"
 ^true

! !
!ListView categoriesFor: #canAcceptReroutedWheel!public! !

!MoenTreeView methodsFor!

canAcceptReroutedWheel

 "Answer whether the view may be scrolled by a rerouted wheel message - true
in this case"
 ^true


! !
!MoenTreeView categoriesFor: #canAcceptReroutedWheel!public! !

!MultilineTextEdit methodsFor!

canAcceptReroutedWheel

 "Answer whether the view may be scrolled by a rerouted wheel message - true
in this case"
 ^true


! !
!MultilineTextEdit categoriesFor: #canAcceptReroutedWheel!public! !

!TreeView methodsFor!

canAcceptReroutedWheel

 "Answer whether the view may be scrolled by a rerouted wheel message - true
in this case"
 ^true

! !
!TreeView categoriesFor: #canAcceptReroutedWheel!public! !

!View methodsFor!

canAcceptReroutedWheel

 "Answer whether the view may be scrolled by a rerouted wheel message -
default is false"
 ^false!

onMouseWheeled: aMouseEvent
 "Handler for a mouse wheel movement event. Accept the default window
processing if the cursor is within the receiver. Otherwise reroute the
MouseEvent message if the view containing the cursor can accept it."

 |pos|
 self presenter trigger: #mouseWheeled: with: aMouseEvent.
 pos := aMouseEvent position.
 (self screenRectangle containsPoint: pos) ifFalse:
  [|test| (self topView allSubViews select:[:view| view
canAcceptReroutedWheel and:
   [view isWindowVisible]])
    keysAndValuesDo: [:i :view|
      (view screenRectangle containsPoint: pos) ifTrue: [test := view]].
  test isNil ifFalse:[^test defaultWindowProcessing: aMouseEvent]].
 ^self defaultWindowProcessing: aMouseEvent! !
!View categoriesFor: #canAcceptReroutedWheel!public! !
!View categoriesFor: #onMouseWheeled:!event handling!public! !

"End of package definition"!

"Source Globals"!

"Classes"!

"Binary Globals"!

"Resources"!

-~-~-~-~-~-~-~-~-~-~-~
End of package text

"Peter Kenny" <[hidden email]> wrote in message
news:[hidden email]...

>  the only
> PITA was finding a way to identify the pane containing the cursor. I have
> cracked this with one minor qualification (see the package comment).

I have now been able to remove the qualification, relating to the class
diagram pane in the Class Browser. The problem turns out to be due to a
'feature' (bug?) in class MoenTreeView. When such a view is contained in a
ScrollingDecorator (which the class diagram is), it reports its screen
rectangle as being the whole extent of the view, not just the portion
visible through the scrolling window. My code detects which view contains
the source of the scroll wheel message by seeing which answers true to:
view screenRectangle containsPoint: aMouseEvent position
This meant that in some cases the cursor could be found to be in two panes,
one being its actual containing pane and the other being the overlap of the
class diagram beyond its actual pane. My code assumes, logically, that only
one pane can answer true to this test, and with multiple answers it
arbitrarily took the latest one in the #allSubViews order of the
ClassBrowser. This was normally the class diagram, hence the erroneous
scrolling.

The remedy is to provide MoenTreeView with an implementation of
#screenRectangle which overrides the default definition in class View and
detects the case where it is contained in a ScrollingDecorator. The method
definition (lifted from the revised package) is:

!MoenTreeView methodsFor!

screenRectangle
 "Override default definition to deal with case of MoenTreeView contained in
a ScrollingDecorator."

 (self parentView isKindOf: ScrollingDecorator)
  ifTrue: [^self parentView screenRectangle]
  ifFalse: [^super screenRectangle]! !
!MoenTreeView categoriesFor: #screenRectangle!public! !

With this change the panes of all the Dolphin tools I have tried scroll
correctly. I have not yet found any bad side effects from the new definition
above.

If anyone would like the updated version of the package, e-mail me.

Peter Kenny