Loading ...
Sorry, an error occurred while loading the content.
 

Scrolling with the mouse scroll wheel when a window is "split"

Expand Messages
  • DBaldon
    I have noticed that if I have a window split (using the splitter bar or Split command) I have to have the mouse pointer in the lower pane for the scrolling to
    Message 1 of 6 , Mar 5, 2007
      I have noticed that if I have a window split (using the splitter bar
      or Split command) I have to have the mouse pointer in the lower pane
      for the scrolling to occur in the upper pane. If the lower pane has
      the focus the mouse pointer can be in either the upper or lower pane
      and the scrolling will occur. It seems to me that the pane that has
      the focus should scroll regardless of the location of the mouse
      pointer OR the pane that the mouse pointer is over should scroll. My
      personal preference is the latter. I don't think you should need to
      change the focus for the scrolling to occur.
    • Michael L. Jones
      I can t reproduce the behavior you described. When I click in either pane to give it focus, that pane scrolls with the mouse scroll wheel no matter where the
      Message 2 of 6 , Mar 7, 2007
        I can't reproduce the behavior you described. When I click in either
        pane to give it focus, that pane scrolls with the mouse scroll wheel
        no matter where the mouse pointer is located. (I am using the latest
        beta version, so it's possible that something was fixed. BTW, a
        release candidate is being tested, so the new version will probably be
        out be out soon.)

        Regarding scrolling based on mouse pointer position rather than window
        focus, I think that would violate the principle of the mouse impacting
        the window (pane, etc.) with focus.

        There is an "X-Mouse" setting in TweakUI that emulates the X-Windows
        standard of giving focus to the window the mouse pointer is over.
        Maybe you should investigate that.

        Oops. I just checked it out, and the split panes in EditPlus do not
        receive focus when under the mouse pointer. Not being an X-Windows
        guy, I don't know if the standard is supposed to apply to split panes.
        If it is, the problem is in the X-Windows emulation, because Excel
        behaves the same as EditPlus.

        --- In editplus@yahoogroups.com, "DBaldon" <dbaldon@...> wrote:
        >
        > I have noticed that if I have a window split (using the splitter bar
        > or Split command) I have to have the mouse pointer in the lower pane
        > for the scrolling to occur in the upper pane. If the lower pane has
        > the focus the mouse pointer can be in either the upper or lower pane
        > and the scrolling will occur. It seems to me that the pane that has
        > the focus should scroll regardless of the location of the mouse
        > pointer OR the pane that the mouse pointer is over should scroll. My
        > personal preference is the latter. I don't think you should need to
        > change the focus for the scrolling to occur.
        >
      • DBaldon
        I m just now getting back to looking into this. The first thing I did was download the latest version and fixes to see if the behavior was changed. For me, it
        Message 3 of 6 , Oct 1, 2007
          I'm just now getting back to looking into this. The first thing I did
          was download the latest version and fixes to see if the behavior was
          changed. For me, it has not not. The same behavior I described in my
          original post still exists.

          --- In editplus@yahoogroups.com, "Michael L. Jones" <mljones1947@...>
          wrote:
          >
          > I can't reproduce the behavior you described. When I click in either
          > pane to give it focus, that pane scrolls with the mouse scroll wheel
          > no matter where the mouse pointer is located. (I am using the latest
          > beta version, so it's possible that something was fixed. BTW, a
          > release candidate is being tested, so the new version will probably be
          > out be out soon.)
          >
          > Regarding scrolling based on mouse pointer position rather than window
          > focus, I think that would violate the principle of the mouse impacting
          > the window (pane, etc.) with focus.
          >
          > There is an "X-Mouse" setting in TweakUI that emulates the X-Windows
          > standard of giving focus to the window the mouse pointer is over.
          > Maybe you should investigate that.
          >
          > Oops. I just checked it out, and the split panes in EditPlus do not
          > receive focus when under the mouse pointer. Not being an X-Windows
          > guy, I don't know if the standard is supposed to apply to split panes.
          > If it is, the problem is in the X-Windows emulation, because Excel
          > behaves the same as EditPlus.
          >
          > --- In editplus@yahoogroups.com, "DBaldon" dbaldon@ wrote:
          > >
          > > I have noticed that if I have a window split (using the splitter bar
          > > or Split command) I have to have the mouse pointer in the lower pane
          > > for the scrolling to occur in the upper pane. If the lower pane has
          > > the focus the mouse pointer can be in either the upper or lower pane
          > > and the scrolling will occur. It seems to me that the pane that has
          > > the focus should scroll regardless of the location of the mouse
          > > pointer OR the pane that the mouse pointer is over should scroll. My
          > > personal preference is the latter. I don't think you should need to
          > > change the focus for the scrolling to occur.
          > >
          >
        • DBaldon
          I m back. [;;)] This issue has come up again as I m dealing with the same issue in another program (it s author has reproduced the problem but has no
          Message 4 of 6 , May 8, 2008
            I'm back. [;;)]

            This issue has come up again as I'm dealing with the same issue in
            another program (it's author has reproduced the problem but has no
            resolution yet). I observed the same behavior yesterday in the Directory
            window. I have mine set so the top 1/3 is for folders and the bottom 2/3
            for files. If I single click a folder (not opening it) and then try to
            scroll the list with the mouse wheel it doesn't scroll. Now if I move
            the mouse over the pane where a file would be, the scroll wheel works.
            The same applies to the files section of the Directory window. Comparing
            that to the behavior of a document pane, it will scroll only when the
            mouse is within it's borders. This is the way I believe things should
            work. Actually I don't think you should have to click a window first
            before being able to scroll it. Just having the mouse over the window
            should cause that window to scroll. I believe this is a matter of being
            aware of which window the mouse is in and then sending the scroll events
            to that window.

            BTW, I'm now using v3.01 (446)

            --- In editplus@yahoogroups.com, "DBaldon" <dbaldon@...> wrote:
            >
            > I'm just now getting back to looking into this. The first thing I did
            > was download the latest version and fixes to see if the behavior was
            > changed. For me, it has not not. The same behavior I described in my
            > original post still exists.
            >
            > --- In editplus@yahoogroups.com, "Michael L. Jones" mljones1947@
            > wrote:
            > >
            > > I can't reproduce the behavior you described. When I click in either
            > > pane to give it focus, that pane scrolls with the mouse scroll wheel
            > > no matter where the mouse pointer is located. (I am using the latest
            > > beta version, so it's possible that something was fixed. BTW, a
            > > release candidate is being tested, so the new version will probably
            be
            > > out be out soon.)
            > >
            > > Regarding scrolling based on mouse pointer position rather than
            window
            > > focus, I think that would violate the principle of the mouse
            impacting
            > > the window (pane, etc.) with focus.
            > >
            > > There is an "X-Mouse" setting in TweakUI that emulates the X-Windows
            > > standard of giving focus to the window the mouse pointer is over.
            > > Maybe you should investigate that.
            > >
            > > Oops. I just checked it out, and the split panes in EditPlus do not
            > > receive focus when under the mouse pointer. Not being an X-Windows
            > > guy, I don't know if the standard is supposed to apply to split
            panes.
            > > If it is, the problem is in the X-Windows emulation, because Excel
            > > behaves the same as EditPlus.
            > >
            > > --- In editplus@yahoogroups.com, "DBaldon" dbaldon@ wrote:
            > > >
            > > > I have noticed that if I have a window split (using the splitter
            bar
            > > > or Split command) I have to have the mouse pointer in the lower
            pane
            > > > for the scrolling to occur in the upper pane. If the lower pane
            has
            > > > the focus the mouse pointer can be in either the upper or lower
            pane
            > > > and the scrolling will occur. It seems to me that the pane that
            has
            > > > the focus should scroll regardless of the location of the mouse
            > > > pointer OR the pane that the mouse pointer is over should scroll.
            My
            > > > personal preference is the latter. I don't think you should need
            to
            > > > change the focus for the scrolling to occur.
            > > >
            > >
            >



            [Non-text portions of this message have been removed]
          • Michael L. Jones
            Let s see if we agree on a couple of things: Pressing a key should perform some action in the window (considering lists and splits as windows) that has focus.
            Message 5 of 6 , May 8, 2008
              Let's see if we agree on a couple of things: Pressing a key should
              perform some action in the window (considering lists and splits as
              windows) that has focus. The scroll wheel should scroll the window
              that has focus.

              If we agree on that, then the question becomes: Can two different
              windows have focus, one for the keyboard and one for the mouse?
              Microsoft thinks that the answer is no. In Windows, the operating
              system, windows only get focus for the mouse when you click in them,
              not when the mouse moves over them.

              Open Windows Explorer with the folder list displayed and play around
              with it. It behaves exactly like EditPlus. This makes sense, since
              most Windows-specific programs use native Windows controls or
              something subclassed from them.

              Now open Firefox, display the bookmarks or history list on the left
              and play around with it. It behaves the way you prefer. (I'm
              sure that there are other examples besides Firefox, but it's what came
              to mind.) Could this be because Firefox is portable across operating
              systems and does not use native Windows controls? (Note that Internet
              Explorer behaves the same as Windows Explorer.)

              So, which is correct? I'd say that EditPlus is following the Windows
              standard, good or bad, established by Microsoft. I think that your
              complaint should be directed to Windows, not to EditPlus.

              --- In editplus@yahoogroups.com, "DBaldon" <dbaldon@...> wrote:
              >
              > I'm back. [;;)]
              >
              > This issue has come up again as I'm dealing with the same issue in
              > another program (it's author has reproduced the problem but has no
              > resolution yet). I observed the same behavior yesterday in the Directory
              > window. I have mine set so the top 1/3 is for folders and the bottom 2/3
              > for files. If I single click a folder (not opening it) and then try to
              > scroll the list with the mouse wheel it doesn't scroll. Now if I move
              > the mouse over the pane where a file would be, the scroll wheel works.
              > The same applies to the files section of the Directory window. Comparing
              > that to the behavior of a document pane, it will scroll only when the
              > mouse is within it's borders. This is the way I believe things should
              > work. Actually I don't think you should have to click a window first
              > before being able to scroll it. Just having the mouse over the window
              > should cause that window to scroll. I believe this is a matter of being
              > aware of which window the mouse is in and then sending the scroll events
              > to that window.
              >
              > BTW, I'm now using v3.01 (446)
              >
              > --- In editplus@yahoogroups.com, "DBaldon" <dbaldon@> wrote:
              > >
              > > I'm just now getting back to looking into this. The first thing I did
              > > was download the latest version and fixes to see if the behavior was
              > > changed. For me, it has not not. The same behavior I described in my
              > > original post still exists.
              > >
              > > --- In editplus@yahoogroups.com, "Michael L. Jones" mljones1947@
              > > wrote:
              > > >
              > > > I can't reproduce the behavior you described. When I click in either
              > > > pane to give it focus, that pane scrolls with the mouse scroll wheel
              > > > no matter where the mouse pointer is located. (I am using the latest
              > > > beta version, so it's possible that something was fixed. BTW, a
              > > > release candidate is being tested, so the new version will probably
              > be
              > > > out be out soon.)
              > > >
              > > > Regarding scrolling based on mouse pointer position rather than
              > window
              > > > focus, I think that would violate the principle of the mouse
              > impacting
              > > > the window (pane, etc.) with focus.
              > > >
              > > > There is an "X-Mouse" setting in TweakUI that emulates the X-Windows
              > > > standard of giving focus to the window the mouse pointer is over.
              > > > Maybe you should investigate that.
              > > >
              > > > Oops. I just checked it out, and the split panes in EditPlus do not
              > > > receive focus when under the mouse pointer. Not being an X-Windows
              > > > guy, I don't know if the standard is supposed to apply to split
              > panes.
              > > > If it is, the problem is in the X-Windows emulation, because Excel
              > > > behaves the same as EditPlus.
              > > >
              > > > --- In editplus@yahoogroups.com, "DBaldon" dbaldon@ wrote:
              > > > >
              > > > > I have noticed that if I have a window split (using the splitter
              > bar
              > > > > or Split command) I have to have the mouse pointer in the lower
              > pane
              > > > > for the scrolling to occur in the upper pane. If the lower pane
              > has
              > > > > the focus the mouse pointer can be in either the upper or lower
              > pane
              > > > > and the scrolling will occur. It seems to me that the pane that
              > has
              > > > > the focus should scroll regardless of the location of the mouse
              > > > > pointer OR the pane that the mouse pointer is over should scroll.
              > My
              > > > > personal preference is the latter. I don't think you should need
              > to
              > > > > change the focus for the scrolling to occur.
              > > > >
              > > >
              > >
              >
              >
              >
              > [Non-text portions of this message have been removed]
              >
            • Gary
              Very nice analysis of the situation, Michael. I wasn t aware of the scrollwheel behavior in Firefox and had to go try it out immediately. Very cool, I must
              Message 6 of 6 , May 9, 2008
                Very nice analysis of the situation, Michael.

                I wasn't aware of the scrollwheel behavior in Firefox and had to go
                try it out immediately. Very cool, I must say. That should be a
                configurable option in EditPlus. Sure it may be difficult to implement
                technically, but that's what programming is all about: jumping through
                hoops to make things as easy for the user as possible.

                This wouldn't be the first time that Firefox has set a UI standard for
                EditPlus to follow. Now, I'm not sure if I can single handedly take
                credit for this feature getting implemented, but I did request that
                EditPlus make the document selector buttons re-orderable via drag &
                drop, just like you can drag & drop the order of the tabs in Firefox.

                I was told that you can reorder the tabs in via the Window list. I
                argued back that I used EditPlus and Firefox together all the time and
                that I couldn't count how many times that I've instinctively tried to
                drag those darn things around in EditPlus. Sure enough, the feature
                showed up in v3. I'm very happy now :)



                --- In editplus@yahoogroups.com, "Michael L. Jones" <mljones1947@...>
                wrote:
                >
                > Let's see if we agree on a couple of things: Pressing a key should
                > perform some action in the window (considering lists and splits as
                > windows) that has focus. The scroll wheel should scroll the window
                > that has focus.
                >
                > If we agree on that, then the question becomes: Can two different
                > windows have focus, one for the keyboard and one for the mouse?
                > Microsoft thinks that the answer is no. In Windows, the operating
                > system, windows only get focus for the mouse when you click in them,
                > not when the mouse moves over them.
                >
                > Open Windows Explorer with the folder list displayed and play around
                > with it. It behaves exactly like EditPlus. This makes sense, since
                > most Windows-specific programs use native Windows controls or
                > something subclassed from them.
                >
                > Now open Firefox, display the bookmarks or history list on the left
                > and play around with it. It behaves the way you prefer. (I'm
                > sure that there are other examples besides Firefox, but it's what came
                > to mind.) Could this be because Firefox is portable across operating
                > systems and does not use native Windows controls? (Note that Internet
                > Explorer behaves the same as Windows Explorer.)
                >
                > So, which is correct? I'd say that EditPlus is following the Windows
                > standard, good or bad, established by Microsoft. I think that your
                > complaint should be directed to Windows, not to EditPlus.
              Your message has been successfully submitted and would be delivered to recipients shortly.